A stolen credential can be revoked immediately, but an identity record often has to remain intact for ownership, audit, and workflow continuity. If the two are conflated, teams either overreact by deleting the record or underreact by leaving the proof valid. The risk is containment failure.
Why the credential and the record do not carry the same risk
A credential is the proof that grants access; a record is the administrative object that tracks who or what owns that access. When those are treated as the same thing, teams either delete the record and break continuity, or keep the credential valid and preserve an unsafe path. The key distinction is that containment works on the proof, while governance often depends on the record.
That separation matters because a record can support approvals, ownership, auditing, recovery, and workflow history even after the proof is revoked. A credential, by contrast, is valuable to an attacker precisely because it can be used immediately. The right response therefore depends on whether you are controlling access or preserving the identity container that access was attached to.
What changes when the proof is stolen versus when the record is altered
Stolen credentials create an active access problem. The credential can be replayed, rotated, revoked, or invalidated, and the main objective is to stop unauthorized use quickly. A changed identity record creates a trust problem. The danger is not just unauthorized access, but also incorrect ownership, broken approvals, misrouted notifications, failed audits, and accidental privilege reassignment.
That is why the containment model is different. If the proof is compromised, you can usually contain the event by removing or replacing the authenticating material. If the record is compromised, you have to restore correctness without destroying the business object that other systems depend on. In practice, those are different failure modes with different blast radii.
- Credential compromise changes who can act.
- Record corruption changes what the organisation believes about that actor.
- Both can coexist, but they should not be remediated with the same action.
Why this distinction matters for access governance and recovery
In mature environments, the identity record is part of lifecycle governance, not just authentication. It may hold ownership, entitlement history, workflow state, and linkage to downstream systems. Deleting or replacing it too aggressively can sever audit trails and create orphaned processes. Leaving it untouched when the credential is stolen can leave an attacker with valid access long enough to move laterally or harvest more privilege.
The practical test is whether the change affects proof, attribution, or administration. Proof problems are handled by revocation and re-issuance. Record problems are handled by correction, reconciliation, and control of downstream propagation. If you cannot keep those two tracks separate, response becomes either overcorrection or undercontainment.
This is also where OWASP Non-Human Identity Top 10 is useful, because it frames secret leakage, overprivilege, and rotation as separate control problems rather than one identity problem. For machine and service credentials, the same distinction shows up in API Key Management Guide and Secrets Management Guide, where revocation, rotation, and lifecycle control are treated as different actions from recordkeeping.
Risk and Threat Considerations
The risk is containment failure: teams either preserve an attacker’s usable proof or destroy the legitimate record needed for continuity. In both cases, the organisation loses control, but the failure looks different operationally, one is unauthorized access, the other is broken governance and auditability.
Failure mechanism: Conflating proof with record leads responders to apply the wrong control, such as deleting the account object instead of revoking the credential, or rotating the credential while leaving bad ownership or delegation in place.
Impact: Attackers may retain access long enough to exploit the environment, while legitimate workflows, approvals, and evidence chains are broken. The result is weaker containment, slower recovery, and less reliable audit evidence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Stolen credentials are a secret leakage problem that must be contained fast. |
| NHI-01 — Improper Offboarding | Record retention and revocation need separate lifecycle handling to avoid bad cleanup. | |
| Recommendation — Revoke leaked secrets immediately and verify no active sessions or tokens remain. Separate proof revocation from account offboarding and preserve the record for governance. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The question hinges on stolen authenticators versus the identity record that stores context. |
| AU-2 — Event Logging | Keeping the record intact supports auditability when credentials are revoked or corrected. | |
| AC-2 — Account Management | Account records must remain manageable even when the authentication proof changes. | |
| Recommendation — Rotate or revoke compromised authenticators without destroying the underlying account object. Log revocation, record changes, and reconciliation actions so containment is auditable. Maintain accurate account records and separate identity lifecycle actions from credential response. | ||
Practitioner Guidance
What to verify: Confirm whether the incident is about authentication material, the account object, or both. If the proof is exposed, invalidate it first; if the record is corrupt, preserve it and repair the metadata separately.
Decision rule: If the object is needed for audit or workflow continuity, do not delete it as a shortcut. Revoke or rotate the credential, freeze risky entitlements, and reconcile ownership after access is contained.
What good looks like: Recovery preserves the identity record, removes the compromised proof, and leaves a clear trace of who approved the change, why it happened, and which downstream systems were updated.
Practitioner takeaway: Treat the credential as the access path and the record as the governance object; mixing them up is what turns a clean containment action into either data loss or ongoing exposure.
Related resources from NHI Mgmt Group
- Why do stolen credentials and compromised identities create more risk than classic perimeter failures?
- Why do stolen credentials create so much more risk when identity is poorly governed?
- Why do stolen endpoint credentials create broader identity risk?
- Why do stolen credentials create such high risk in cloud identity attacks against SaaS and IdPs?