Who should be accountable for assurance drift in federated identity programmes?

Why This Matters for Security Teams

Assurance drift is not just an identity-program hygiene issue. In federated identity programmes, the risk is that proofing strength, authentication controls, and federation policy slowly diverge from the assurance level the business thinks it is getting. That gap can open access to high-value apps, partner portals, and privileged workflows without any obvious outage or alert. Current guidance from NIST SP 800-63 Digital Identity Guidelines makes clear that assurance is a lifecycle property, not a one-time setup decision.

NHI Management Group research shows how often identity control assumptions fail in practice: in the Ultimate Guide to NHIs, 90% of IT leaders said properly managing NHIs is essential for a successful zero-trust implementation, yet 68% of organisations do not know how to fully address NHI risks. The same pattern shows up in federated environments when no single team owns assurance integrity across the full trust chain. In practice, many security teams discover assurance drift only after a partner incident, not through intentional review.

How It Works in Practice

Accountability should follow the control points that can actually cause drift. Proofing teams own the original identity evidence and vetting rules. Authentication teams own how strongly an identity is challenged at login and step-up. Federation teams own the assertions, mappings, token claims, and trust relationships that external relying parties consume. If any one of these teams weakens its layer without coordinated review, the programme can still appear healthy while the effective assurance level drops.

A practical operating model uses shared thresholds and explicit review gates. For example:

• Proofing teams define identity proofing levels and evidence retention requirements.
• Authentication teams set acceptable factors, reauthentication intervals, and recovery paths.
• Federation teams enforce issuer trust, claim release, audience restrictions, and signing policy.
• Security governance reviews exceptions, compensating controls, and periodic revalidation against policy.

That approach aligns with the lifecycle thinking in NIST SP 800-63 Digital Identity Guidelines, which treats assurance as something that can rise or fall as evidence ages, credentials change, or recovery processes weaken. It also reflects the broader pattern seen in the 52 NHI Breaches Analysis, where control failures often emerge at handoffs rather than in a single product or team. The accountable owner is usually the programme function that can force reconciliation across those handoffs, not the downstream app team that only consumes the assertion.

These controls tend to break down when multiple business units federate independently and no shared assurance baseline exists because each domain optimises for local convenience rather than enterprise-wide trust consistency.

Common Variations and Edge Cases

Tighter assurance governance often increases operational overhead, requiring organisations to balance user friction against the cost of silent trust degradation. In some programmes, the federation team is formally accountable for drift because it controls the trust broker and can block weak assertions. In others, IAM owns the policy but must rely on business application owners to approve exceptions. There is no universal standard for this yet, so the best practice is evolving toward shared accountability with one named control owner.

Edge cases matter. If external identity proofing is outsourced, the vendor may execute the process, but accountability still sits with the programme that accepts the risk and defines acceptance criteria. If legacy apps cannot consume step-up or richer claims, the risk must be documented as an exception with a review date, not allowed to become permanent. For partner federation, drift can also occur when signing keys, token lifetimes, or claim release rules change outside the normal change advisory process.

Security leaders should use drift reviews to test whether policy still matches reality, especially after mergers, new partners, or recovery events. Where assurance is materially important, a control owner should be named, thresholds should be versioned, and exceptions should expire automatically. The Top 10 NHI Issues research is a useful reminder that unmanaged trust sprawl is usually a governance failure first and a technical failure second.

Related resources from NHI Mgmt Group

• Who should be accountable for certificate trust decisions across identity programmes?
• Who is accountable when identity security controls fail across IAM, PAM, and NHI programmes?
• Why does access drift happen in cloud identity programmes?
• Why do identity governance programmes fail when integrations are too narrow?