Who is accountable when a digital identity platform is used for fraud or unauthorised changes?

Accountability usually spans the identity operator, the relying service, and the organisation that owns the recovery or modification process. When identity is shared infrastructure, responsibility cannot stop at login. Governance must cover enrollment, mutation, consent, and offboarding, because any weak handoff can become the attacker’s entry point.

Why This Matters for Security Teams

When a digital identity platform is used for fraud or unauthorised changes, the failure is rarely limited to one control or one team. The practical issue is accountability across the identity lifecycle: who approves enrollment, who can mutate attributes, who can recover access, and who can revoke it. That matters because identity systems are shared infrastructure, and weak governance at any handoff can turn a legitimate platform into a fraud path.

For NHI programmes, this is a familiar pattern. The Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and that only 20% of organisations have formal offboarding and revocation processes. That is a governance problem, not just a technical one. The same lesson appears in 52 NHI Breaches Analysis: once identity becomes operational plumbing, bad changes are often discovered after damage has already propagated.

Security teams get this wrong when they assume the login provider owns all risk, or that the relying service is solely responsible for downstream abuse. In practice, many teams encounter accountability gaps only after fraudulent recovery, unauthorised attribute changes, or privilege escalation has already occurred.

How It Works in Practice

Accountability should be mapped to the specific action that failed. Enrollment is owned by the process that admitted the identity. Mutation is owned by the service that allowed attributes, roles, or recovery factors to change. Transactional use is owned by the relying application that accepted the identity assertion. Offboarding is owned by the organisation that decides when the identity should no longer be trusted. NIST’s Cybersecurity Framework 2.0 is useful here because it pushes teams to assign governance, identify dependencies, and verify that controls exist across the lifecycle, not just at authentication.

For NHI and agentic environments, current guidance suggests treating identity as an operational control plane rather than a single login event. That means:

• Separating who can create an identity from who can approve its privileges.
• Logging consent, recovery, and attribute changes with immutable audit trails.
• Using least privilege and short-lived access so one compromise does not persist.
• Requiring explicit owners for revocation, rotation, and exception handling.
• Testing fraud paths, not just password resets and sign-in success.

This is where NHI-specific governance matters. The Top 10 NHI Issues highlights excessive privilege, weak rotation, and poor visibility as recurring patterns. If a platform allows unauthorised changes through stale credentials or weak recovery workflows, the accountable party is usually the one that failed to design and operate those workflows with sufficient control. In practice, these controls tend to break down in federated environments with delegated administration because ownership is split across teams and audit trails stop at system boundaries.

Common Variations and Edge Cases

Tighter identity governance often increases operational overhead, so organisations must balance fraud resistance against user support and recovery friction. That tradeoff is real, especially where multiple parties share the same identity stack or where third-party services can trigger account changes.

There is no universal standard for this yet, but best practice is evolving toward shared accountability models. In outsourced identity platforms, the operator may manage uptime and core controls, while the customer remains accountable for policy, approvals, and business use. In delegated recovery flows, the relying service is accountable for validating claims before it accepts a change, even if the identity provider issued the token. For fraud cases, the most important question is not only “who authenticated the user?” but “who allowed the change, under what policy, and with what evidence?”

That distinction is especially important in high-volume environments such as CI/CD, customer identity, and service-account governance. NHIMG research on the CI/CD pipeline exploitation case study shows how trusted automation paths can be abused when mutation and approval are not tightly separated. When identity recovery is treated as a convenience feature rather than a controlled security workflow, accountability becomes ambiguous and fraud becomes easier to deny after the fact.

Related resources from NHI Mgmt Group

• Who is accountable when a mobility platform is used for fraud or laundering?
• Who should own digital identity trust when fraud, IAM, and compliance overlap?
• Who is accountable when identity fraud succeeds through weak verification?
• Who is accountable when stolen credentials from a phishing email are used for fraud?