After single sign-on is enabled, an employee opens the travel-expenses system and finds an empty history. The old reports still exist: the application has simply created another profile. The login demonstration passed, but the employee now has to establish that the previous account belongs to them too.
Single Sign-On makes moving between applications easier by reusing a trusted authentication result. The project extends beyond a new button. Existing accounts must be linked, correct permissions preserved, and changes of role or employment translated into actual application access.
One sign-in is not one password copied everywhere
In a federated design, an application redirects the user to an Identity Provider. The provider authenticates them and returns confirmation through a protocol such as SAML or OpenID Connect. Each product need not receive the primary password. This differs from password-filling mechanisms also marketed as SSO; the Microsoft Entra overview distinguishes the approaches.
The application must verify the confirmation's source, intended recipient and validity for the sign-in attempt. It commonly establishes its own session afterwards. What feels like one continuous experience rests on several separate trust relationships.
Additional authentication for a sensitive action is compatible with SSO. Approving a routine request and changing payment details carry different risks. Convenience means avoiding unnecessary repetition, not promising never to verify identity again.
Email is a poor permanent account identifier
An address can change after a name or domain change and may later be assigned to someone else. Automatically merging accounts on an email match is therefore risky. OpenID Connect uses the issuer and subject together — iss and sub — as a stable identifier. The specification explains why other profile fields do not carry the same guarantee.
Migration needs a verified mapping from the old account to the new identity. Investigate ambiguity rather than giving the first similar-looking user access to somebody's history. For expenses, test past approvals, unfinished reports and delegated permissions, not just whether a dashboard opens.
External participants may belong to different organisations and authentication systems. Similar display names do not make them the same security principal. Organisation membership must remain explicit, especially in a product serving several corporate customers.
Provisioning an account is not authenticating it
SSO does not necessarily create, update or deactivate every application's user record. Those tasks may use separate interfaces, including SCIM. Microsoft's provisioning guidance distinguishes this lifecycle management from federation-based sign-in.
Creating a profile on first login can be convenient. It still needs rules about who may receive an account and which permissions it initially carries. A successful sign-in should not silently confer administration of a newly created organisation.
A role change also requires removing old privileges. Updating a central group does not fix a separate local permission that an application retains. Give each mapping from directory groups to product actions an owner and measure how long changes take to become effective.
Logout, blocking and offboarding have different outcomes
Signing out of an application, ending the provider session and removing all employee access are separate actions. An application may continue accepting its own session after new sign-ins are blocked. Microsoft's access-revocation guidance explicitly notes that Entra cannot directly revoke another application's session token.
Agree on actual termination: how the application learns of a block, when previous sessions stop working, and what happens to mobile clients. Single logout depends on participating applications and configuration, not the button's label.
Personal API tokens, local passwords and integrations may follow separate lifecycles. Include them explicitly in offboarding. Revoking a session cannot erase reports already downloaded; handling those copies is another responsibility.
The common login becomes a common dependency
A provider outage may prevent fresh sign-ins while some established sessions keep working. One long-open browser tab is a poor outage test. Try a new browser, an expired session and recovery after the dependency returns.
Administrators need a controlled route to correct a broken shared policy. Its design must address the failure being considered: a backup login using the same unavailable chain offers little help. Microsoft's emergency-access guidance discusses dedicated accounts and monitored use. Leaving a permanent bypass for everyone is not the same thing.
Centralised identity also raises the importance of administrator protection and account recovery. Extra authentication on the main screen is little comfort if support can be persuaded to hand an account to the wrong person. Nor should federation distribute profile data applications do not need.
Connect a few applications completely
Choose a pilot with different applications: a modern one, one with historical accounts and an external service. Walk through an ordinary working day, an email change, a transfer and offboarding with sessions still open. Check both the interface and other client paths actually used.
The cost includes integration, licences, maintenance and remaining manual tasks. An existing provider's service may be sufficient; building a separate identity platform is not mandatory. For every application, establish a revocation time, a permissions-change process and an exception owner. Then “one sign-in” describes usable access under control rather than an identical page in front of several unrelated account problems.