Who is accountable when a federated partner account should no longer have access?

Both sides have responsibility, but the relying party remains accountable for the access it allows. The partner must deprovision correctly, while the relying institution must certify that access remains appropriate and remove it when the business need ends or the assurance level no longer meets policy.

Why This Matters for Security Teams

federated access is easy to grant and hard to retire. Once a partner account is trusted, the real risk is not just initial onboarding, but stale authorization that survives after the business need ends, the relationship changes, or the assurance level drops. That makes accountability a shared operational issue, not a one-time contract point. Guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s Ultimate Guide to NHIs both point to lifecycle control, entitlement review, and offboarding as core security duties rather than administrative cleanup.

The relying party cannot outsource residual risk to the partner, because it is the relying party that continues to accept the authentication result and permit access to internal systems. That is why this question matters in incident response, access reviews, vendor management, and federation design. When the relationship ends but the account still works, the blast radius is usually larger than teams expect. In practice, many security teams encounter unauthorized partner access only after a contract has expired or an audit has exposed dormant entitlements, rather than through intentional offboarding.

How It Works in Practice

Accountability in federated access should be divided by function, not by blame. The partner organization is responsible for deprovisioning the identity source correctly, disabling credentials, and stopping assertions for users or service identities that no longer belong. The relying party is responsible for deciding whether that access should continue, enforcing policy at the point of use, and revoking access when the business justification no longer exists. NIST guidance on access control in NIST SP 800-53 Rev 5 Security and Privacy Controls supports this model by treating authorization as an ongoing control, not a one-time event.

Operationally, mature teams tie federation governance to a few concrete practices:

• Define an internal owner for every partner relationship, system, and entitlement set.
• Require periodic recertification of federated access, especially for privileged or high-impact systems.
• Use short-lived assertions and session limits so access naturally expires if not renewed.
• Revoke trust at the relying party when the partner no longer meets policy, even if the partner has not yet cleaned up its directory.
• Log evidence of approval, recertification, and revocation so accountability is auditable.

NHIMG data shows why this discipline matters: only 20% of organisations have formal processes for offboarding and revoking API keys, and 91.6% of secrets remain valid five days after notification, which is a strong indicator that remediation lags are common. The same problem appears in federated identity, where access can persist long after the need disappears. The Ultimate Guide to NHIs frames this as a lifecycle failure, not just an IAM configuration issue.

These controls tend to break down in partner ecosystems with many indirect trusts because no single team owns the full access chain and revocation becomes dependent on manual coordination.

Common Variations and Edge Cases

Tighter federation controls often increase operational overhead, requiring organisations to balance revocation speed against partner friction and audit burden. That tradeoff is real, especially when business units rely on external providers for recurring access or machine-to-machine integrations. Current guidance suggests treating high-risk partners differently from low-risk ones, but there is no universal standard for this yet.

Edge cases usually emerge when a partner account is shared, delegated, or used for both human and automated access. In those environments, the relying party may need separate approval paths, shorter session durations, and stricter recertification than the partner’s own internal policy. For service accounts and API-driven federation, the same principle applies: if the relying party still accepts the token or assertion, the relying party remains accountable for the exposure. NHIMG’s 52 NHI Breaches Analysis and the OWASP NHI guidance both reinforce that weak lifecycle control is a recurring root cause, especially where third-party access is left to stale trust relationships.

In practice, the cleanest operating model is simple: the partner disables what it owns, and the relying party continuously verifies whether access still belongs. When assurance is uncertain, the safest choice is to remove the access and require re-approval rather than assume the federation layer will self-correct.

Related resources from NHI Mgmt Group

• Who is accountable when a reset or recovery call is used to steal access?
• Who is accountable when a travelling clinician keeps access after the assignment ends?
• Who is accountable when clinical access is over-provisioned or not removed?
• Who is accountable when a homegrown IAM process fails an audit or leaves access active too long?