When an enterprise buys a translation tool, the functional evaluation usually takes a week. What actually stretches the timeline is the security review. IT and legal care about a different set of questions than the business does: how identities are managed, where data lives, how access is revoked when someone leaves, and whether an incident can be reconstructed from logs. This is about that side of the deployment.
SAML 2.0: get the three roles straight first
Single sign-on configuration goes wrong mostly because the three roles get blurred. The identity provider (Okta, Azure AD, OneLogin) authenticates the user. The service provider -- the application -- consumes the assertion and grants access. The browser only carries the assertion between them.
Three values decide whether it works: entity ID, assertion consumer service URL, and the signing certificate. Entity IDs must match exactly on both sides, including scheme and any trailing slash. A wrong ACS URL sends assertions to the wrong endpoint and presents as a blank page after login. Certificate expiry is the single most common cause of outages -- set a reminder 30 days out and rotate before it lapses.
SCIM: automate the account lifecycle
Configuring SSO without SCIM is a very common gap. SSO answers how someone signs in; SCIM answers who should exist at all. Without it, joiners are created by hand and leavers are removed by hand -- and the second half is what gets forgotten.
With SCIM connected, user creation, attribute updates, deactivation, and deletion propagate automatically from the IdP. Department attributes can map to team membership, and job level can map to permission groups. One practical note: keep deactivation and deletion distinct. Deactivation preserves data for handover; deletion actually removes it -- and deleting a user outright takes their glossaries and translation memories with them.
Match session lifetime to risk
Session timeout is a direct trade between security and usability. Too short and people find ways around it after the fourth login of the day. Too long and a session on a shared machine becomes an exposure.
A reasonable pattern is tiered: 8 to 12 hours on a trusted corporate network, covering one working day; one hour with step-up authentication from untrusted networks; and a shorter, separate timeout for administrative surfaces. Also confirm that single logout actually works end to end -- in many deployments SSO is configured correctly but sign-out only clears the application session, leaving the IdP session alive and a new tab logged straight back in.
Write the data boundary into the contract
The hardest part of a security review is usually not technical, it is data flow. You need clear answers on where submitted text is processed, how long it is retained, whether it is used for model training, which sub-processors are involved, and the notification window if there is a breach.
The data security documentation and content deletion policy cover retention and deletion terms. For regulated sectors -- finance, healthcare, government -- confirm available processing regions during selection, not after go-live. That is not a setting you can change later.
Audit logs are useless if you enable them after the incident
Audit logging has value only if it was already running and retained long enough. At minimum cover successful and failed logins, permission changes, glossary and style rule edits, bulk exports, and administrative actions.
Logs also need to export into the company SIEM. Being visible in an application console is not sufficient -- a security team will not pivot into a separate console for one vendor. Align retention with your overall compliance obligations; finance and healthcare commonly require anywhere from six months to seven years.
Roll out in stages
Four steps work well. Pilot with roughly 20 people inside IT to validate the full SSO and SCIM path. Expand to one or two business units and check whether the permission model holds up against real usage. Open it to everyone while keeping local accounts as a fallback. Finally, disable local accounts and enforce SSO.
Leave a week or two between stages. The failure that consistently appears only after scaling is permission group design -- with 20 pilot users, access is verified by hand; at several hundred, the structural flaws surface. For the broader deployment picture see the enterprise solutions or contact sales for security review materials.