Why does account federation not solve identity governance on its own?

Why This Matters for Security Teams

Account federation reduces password sprawl, but identity governance fails when teams mistake a single sign-in path for a complete identity record. In most enterprises, the real exposure sits outside the federated directory: legacy accounts, shared service accounts, API keys, local admin accounts, and cloud-native identities that never pass through the same lifecycle controls. NIST Cybersecurity Framework 2.0 stresses that identity governance must support asset and access visibility across the environment, not just at the login layer.

NHIMG research shows the scale of the problem: only 5.7% of organisations have full visibility into their service accounts, and NHIs outnumber human identities by 25x to 50x in modern enterprises. That means federation can improve authentication hygiene while leaving material governance gaps untouched, especially where audit evidence, ownership, and offboarding remain fragmented. The issue is not whether users can sign in centrally. The issue is whether the organisation can answer, with confidence, what accounts exist, who or what controls them, and when they should be revoked. In practice, many security teams discover the gaps only after a breach review exposes accounts that were never in scope for federation or access recertification.

How It Works in Practice

Federation centralises authentication, usually through SSO and an identity provider, but governance requires a broader control plane. A person may authenticate through a federated account while still retaining non-federated local accounts in SaaS tools, orphaned directory entries in acquired environments, or privileged access paths in infrastructure and automation systems. That is why identity governance has to reconcile identity subjects across multiple sources and then map each subject to every account, secret, and entitlement they can use.

For practitioners, the operational pattern is straightforward but rarely complete on day one:

• Inventory all account types, including human, service, local, break-glass, and vendor-managed accounts.
• Link those accounts to a single subject record where possible, while flagging ambiguous ownership for review.
• Feed federated and non-federated accounts into the same access review and offboarding workflow.
• Apply lifecycle controls to secrets and credentials, not only to interactive logins.

That lifecycle view is central to Ultimate Guide to NHIs and its Lifecycle Processes for Managing NHIs section, which aligns with the practical reality that federation does not rotate keys, retire dormant accounts, or revoke machine credentials on its own. Current guidance suggests treating federation as an authentication improvement, not an identity governance endpoint. If evidence of account ownership, rotation, and revocation lives in separate systems, the governance model is still incomplete. These controls tend to break down in hybrid environments where SaaS, on-premises directories, and cloud workloads all maintain their own account stores because subject reconciliation becomes inconsistent.

Common Variations and Edge Cases

Tighter federation and reconciliation controls often increase operational overhead, requiring organisations to balance governance accuracy against migration complexity. The tradeoff is especially visible during mergers, application modernisation, and third-party integrations, where some accounts cannot be federated quickly and must remain local for business continuity. Best practice is evolving here, and there is no universal standard for how aggressively to force convergence across every system.

Three edge cases matter most. First, service accounts used by applications or automation often have no human sign-in flow at all, so federation is irrelevant unless those identities are separately governed. Second, break-glass and emergency access accounts may intentionally bypass federation for resilience, which means they need compensating controls, not exemption from oversight. Third, shadow or duplicate identities can persist when one person has multiple records across directories, contractors, and legacy systems. NHIMG’s Top 10 NHI Issues and 52 NHI Breaches Analysis both reinforce a practical point: governance failures usually come from incomplete inventory and weak lifecycle enforcement, not from federation itself. NIST Cybersecurity Framework 2.0 remains the right reference point for extending identity governance beyond login centralisation and into continuous oversight.

Related resources from NHI Mgmt Group

• Who should own phishing-resistant MFA governance across the identity programme?
• Who should own identity governance when financial-sector controls expand?
• Why is it important to integrate identity and data governance?
• Why do secret managers not solve non-human identity governance on their own?