SafeSend logins are moving to Thomson Reuters Accounts! This change is set to take place on April 25th, 2026.
This will create one unified account for all your Thomson Reuters products.
Firms that use SSO will need to complete the steps below. We will create a Thomson Reuters Account for you and provide a random password. Firms then have two choices:
- No longer use SSO: When you log in to SafeSend, you will need to reset your password, and you can log in as normal.
- Continue using SSO: You will need to connect your SSO account with your Thomson Reuters Account before or after the migration. See the Administrators: Federated Single Sign-On for the Thomson Reuters Account article for more information.
If SSO is not configured before April 25th, 2026, users can reset their password and use a username/password to log in until SSO configuration is complete. They should set up SSO in their Thomson Reuters Account ahead of time to continue their firm's SSO process without interruption.
If the user is already Federated with Thomson Reuters SSO, then the existing email they use for that will work for SafeSend as well, post migration. If they already use SSO for TR and their email address for that matches their SafeSend email address, no additional action is required.
Thomson Reuters Account and SSO
The TR Account Login Platform is a shared platform that supports many Thomson Reuters products. Federation of a product on this platform will result in all products your organization accesses moving to Federation. A listing of the affected products and solutions your organization's users can be found at the end of this document.
To minimize administration and to provide the most secure authentication method, the TR Account team will be working with your IT team to transition your firm to Single Sign On (SSO) Account Federation with your firm’s Workforce Identity Access Management (IAM) service, for Thomson Reuters products and solutions already using TR Account. This change will be nearly transparent to end-users and not impact the access or functionality of the product.
Products and solutions currently using other Thomson Reuters login platforms are not affected by this change
It is important to note that this SSO configuration for the TR Account does not affect TR products and solutions using other TR Login platforms. For example, products and solutions that currently use other authentication platforms, such as ONESOURCE products, and many others. These solutions will migrate from ONESOURCE to TR Account later under a separate program as we continue our journey to provide even better integration and interoperability between our Thomson Reuters family of solutions.
What is the benefit of SSO?
Following the transition to SSO, your users will use credentials fully managed by your Workforce Identity Access Management (IAM) service through account federation and be subject to your security policies for password strength, 2-factor authentication, and any other policies enforced by your identity provider configuration. When SSO is turned on, an employee who leaves the organization will no longer be able to access any TR Account product they are logging into once their IAM account is disabled. For more information regarding the benefits and implementation details of SSO, please see this guide. A member of the Thomson Reuters Account team will contact your designated IT staff to guide the SSO configuration.
How it works for users
As part of the configuration, we will configure the email domain(s) your users use to force login with your IAM credentials. Here’s how it will work:
- Users will open their Thomson Reuters application that is using TR Account authentication and sign in. For example, navigating to the Thomson Reuters Account Profile App at https://www.thomsonreuters.com/en-us/profile
- The Thomson Reuters application will redirect to the Thomson Reuters Account sign-in page. Prior to the SSO transition, the user would be asked for an email address and password they had setup within TR Account. Following the SSO transition, the user will be asked just for their firm-associated email address.
- The user will enter their email address associated with your firm and click “Sign in”.
- The Thomson Reuters Account service will redirect them to your Workforce IAM service for authentication. The screens seen at this point will be dependent on your IAM service.
- Your Workforce IAM service will authenticate the user (or use an existing authentication session) and redirect back to the Thomson Reuters Account service.
- Behind the scenes, the Thomson Reuters Account service will look for an existing account that matches the Federated account email address. If it finds an account that matches it will link the two accounts, and the user will be signed-in seamlessly to the application. If it does not find the account, a new account will be created and there may be issues accessing the application as that new account may not have been given access to the underlying product. In this scenario, contact your application support team to help resolve this issue. In many cases, there may be an administrator within your organization that can give you access to the application you are trying to access.
NOTE: A common scenario where access issues can occur is when someone has changed their name (and email address) through their company but has not done so on the Thomson Reuters Account platform. In this case, a match would not be found, and a new account will be created on the Thomson Reuters account platform. Please reach out to a Thomson Reuters contact who will be able to get this issue resolved.
What products and solutions will be affected, and how?
The following products and solutions your firm is using have been launched with the TR Account or have already migrated to the TR Account. After the SSO transition, the products and solutions noted below will have a minor change to the login flow. Rather than being prompted for both an email address and password on the Thomson Reuters Account Sign in page and then immediately be directed into the product, users will instead first provide their email address associated with the firm and then be directed to your firm’s Workforce IAM service for credentials managed by your firm, as outlined in the “How it works for users” section above. While this change to use SSO should be familiar to your users, you may want to proactively inform the users of these products and solutions to anticipate the change to use SSO during login.
Note: The entitlement or access control to these products is not changing. You should continue to work with your customer service specialist or account management system for requesting or managing access to your Thomson Reuters products.
Current Thomson Reuters products using TR Account will now be directed to your firm’s Workforce IAM service on login.
Configuration Steps
To get the process started we are going to require the following information to configure the Federated connection on the Thomson Reuters Account. This info includes:
- Email Domain(s) that will need to be federated
- The Federated Metadata URL that you will get from the SSO connection you set up on your IDP
Use the following information to configure the connection on your side:
Identifier Entity ID: trtasso.thomson.com (NOTE: If you already have a connection using this Identifier Entity ID use trtasso.thomson.com_CIAM Also, there may be an additional step required which will be reviewed when someone from the TR Customer SSO team reviews the connection with you)
ACS (Assertion Consumer Service)/Destination/Recipient/Reply URL: https://trtasso.thomson.com/sp/ACS.saml2
SAML Attributes:
| Name | Value |
| Name ID (Subject) | A value that is both unique and persistent. Do not use an email address as that can change over time. In Azure Entra ID you can set this as user.objectid |
| emailaddress | Email Address of the User |
| givenname | First name of user |
| surname | Last name of user |
| name | Full Name of User |
As mentioned earlier, once you have created this application, you can pull the Federated Metadata URL from the connection and send it back to us. Our preference is to obtain the Federated Metadata URL rather than the XML, but if the XML is all that is available, that is ok as well.
Comments
Article is closed for comments.