Identity and security
SSO
Single Sign-On
Single Sign-On lets a user authenticate once against a central identity provider and then access multiple separate applications without being prompted to sign in again for each one.
Why SSO matters in a Microsoft estate
SSO matters because identity, access, endpoint, and data controls shape how Microsoft environments are protected. Readers should understand the term and then be able to move into security assessment, conformity, or remediation guidance.
How SSO shows up in practice
This is the mechanism that makes a large application estate practically usable, since without it every application effectively holds its own password. Both password fatigue and the resulting helpdesk cost of password resets scale directly with the number of separate credentials a user has to manage. In the Microsoft ecosystem, Entra ID acts as the identity provider for SSO using standard federation protocols, principally SAML and OpenID Connect with OAuth 2.0, with WS-Federation still present for some legacy line-of-business applications. Thousands of pre-integrated applications are available through the Entra ID application gallery, with SSO configuration largely templated rather than built from scratch. Applications outside the gallery can still be integrated manually, as long as they support one of the standard protocols.
Provisioning is a closely related but distinct capability, usually delivered through SCIM, which automatically creates, updates, and disables user accounts inside the target application as they change in Entra ID. SSO handles authentication while SCIM handles the account lifecycle behind it. Deploying SSO without also wiring up provisioning is a common gap that leaves accounts in target applications not actually synchronised with their source of truth, meaning a disabled Entra ID account can still leave an active, orphaned account sitting in a downstream application. For hybrid environments still running on-premises Active Directory, Seamless SSO uses Kerberos against the on-premises domain to let domain-joined devices sign in without any prompt at all on the corporate network.
Password-based SSO offers a lighter-weight option for older applications that only support form-based login instead, storing and autofilling credentials through the browser extension rather than true federated authentication. The security trade-off inherent to SSO is worth being explicit about. Centralising authentication into one identity provider is what makes broad access manageable, but it also means that single identity provider account becomes a genuinely high-value target, since compromising it can cascade into every connected application at once rather than just one. This is exactly why SSO is deployed in practice alongside Multifactor Authentication and Conditional Access rather than as a standalone convenience feature, and why session lifetime and reauthentication frequency settings for sensitive applications need deliberate configuration rather than being left at defaults that favour convenience over risk.