Why should organisations put identity governance before rolling out SSO and MFA?

Why Identity Governance Has to Come Before SSO and MFA

SSO and MFA are control multipliers, not identity fixes. If the underlying identity record is incomplete, stale, or misclassified, those tools simply automate bad decisions at scale. Identity governance establishes who should have access, what attributes are trusted, and when entitlements should change. That matters because privileged sprawl and weak lifecycle control are already common failure patterns in identity-driven environments, as reflected in NHIMG research on Ultimate Guide to NHIs and the Top 10 NHI Issues.

In practical terms, organisations that deploy SSO first often centralise convenience before they have centralised control. That can hide duplicate accounts, orphaned access, and overbroad group membership behind a clean login experience. NIST Cybersecurity Framework 2.0 makes the same point operationally: identity, access, and governance need to be defined as part of the security function, not bolted on after rollout. In practice, many security teams discover entitlement drift only after a user leaves, a role changes, or an audit exposes access that no one can explain.

What Identity Governance Enables Before Authentication Becomes a Control Plane

Identity governance gives SSO and MFA something reliable to authenticate against. It creates the authoritative inventory of users, service accounts, and access relationships, then ties each identity to a role, attribute set, manager, or business process. Once that foundation exists, SSO can reduce password sprawl without merging unrelated identities, and MFA can be targeted based on risk instead of applied blindly to every account and workflow.

• Clean identity inventory: remove duplicates, dormant accounts, and unowned access before centralising sign-in.
• Trusted attributes: standardise department, job function, privilege level, device trust, and joiner-mover-leaver data.
• Policy-based access: define what access is allowed, what requires review, and what must be time-limited.
• Lifecycle enforcement: revoke or adjust entitlements when roles change, not after the next audit cycle.
• Exception handling: document and approve edge cases instead of letting them become permanent access paths.

For identity programs that include non-human identities, the same rule applies, only more urgently. NHIMG’s Oasis Security & ESG research reports that 72% of organisations have experienced or suspect a breach of non-human identities, which is a strong signal that governance gaps are not theoretical. Once governance is in place, MFA can be targeted where risk justifies friction, and SSO can enforce consistent session policy without masking privilege creep. That sequencing aligns with the NIST Cybersecurity Framework 2.0 emphasis on identity management as a foundation for access control. These controls tend to break down in federated environments with many legacy apps because identity attributes are inconsistent across directories and trust boundaries.

Where the Sequence Breaks, and What Teams Need to Watch

Tighter identity governance often increases operational overhead, requiring organisations to balance faster rollout against the cost of cleaning identity data and redesigning access rules. That tradeoff is real, especially when business leaders want rapid SSO adoption across cloud apps, contractors, and acquired subsidiaries. Current guidance suggests that rushing MFA before governance can even create false confidence, because strong authentication does not prevent a misbound account from inheriting the wrong access.

The edge cases are usually the hardest part. Shared administrative accounts, vendor access, service principals, and emergency break-glass identities all need explicit governance because they do not fit a standard employee lifecycle. Best practice is evolving here, especially for machine identities and delegated access, but there is no universal standard for how every organisation should model these exceptions. The practical rule is simple: if the identity cannot be classified, reviewed, and revoked on a known schedule, it should not be pulled into broad SSO federation yet.

Teams also need to separate authentication from authorisation in their rollout plans. MFA confirms the caller, but governance determines whether the caller should still have access at all. Without that separation, organisations risk improving login assurance while leaving excessive privilege untouched, which is exactly the kind of control gap that later shows up in access reviews, incident response, and audit findings.

Related resources from NHI Mgmt Group

• Should organisations prioritise identity governance before expanding agentic AI?
• Should organisations rely on SSO and MFA as their main identity controls?
• What should organisations check before rolling out zero standing privilege at scale?
• Should organisations tighten access reviews before rolling out Copilot?