Who is accountable when organisations issue credentials without adequate identity verification controls?

Why This Matters for Security Teams

Issuing credentials without adequate identity verification is not just a weak onboarding step. It is a control failure that can undermine access governance, incident response, and regulatory defensibility at the same time. When an organisation cannot prove who was enrolled, who approved exceptions, or what evidence was used, it weakens every downstream control that depends on trusted identity.

NIST’s identity guidance in NIST SP 800-63 Digital Identity Guidelines makes clear that identity proofing and authentication assurance are separate concerns, and both matter. For non-human identities, the same logic applies to service accounts, API keys, and workload credentials. NHI Management Group’s 52 NHI Breaches Analysis shows how often breaches begin with weak issuance, poor secret handling, or unknown ownership.

The practical problem is that identity teams, IAM owners, and business approvers often treat issuance as a formality rather than a risk decision. In practice, many security teams encounter compromise only after an exposed credential has already been used for access, not during the original enrollment review.

How It Works in Practice

Accountability usually follows control ownership. The team that defines identity proofing and enrollment rules owns the control design; the team that operates IAM or PAM owns implementation and monitoring; and the business owner who requested the credential often owns the risk acceptance for exceptions. Where regulated environments are involved, legal, compliance, and audit functions may also be accountable for ensuring the process meets external requirements.

The safest approach is to separate three decisions: who may request a credential, what verification is required before issuance, and who can approve exceptions. That means requiring evidence for identity proofing, logging the approval path, and tying each credential to a named owner and lifecycle. For machine identities, current guidance increasingly favours workload identity and short-lived secrets rather than static long-lived credentials. The OWASP Non-Human Identity Top 10 treats weak issuance, overprivilege, and unmanaged secrets as recurring failure modes, while Ultimate Guide to NHIs explains why secret sprawl and ownership ambiguity so often lead to exposure.

• Use documented identity proofing steps for human users before any privileged credential is issued.
• Require explicit approval for exceptions, with expiry dates and compensating controls.
• Prefer just-in-time issuance and dynamic secrets over static credentials with no review trail.
• Record who requested, who approved, who issued, and who owns revocation.
• Review whether the credential can be traced to a validated identity at audit time.

These controls tend to break down in fast-moving cloud and DevOps environments because teams prioritise speed, reuse shared secrets, and bypass formal verification to avoid release delays.

Common Variations and Edge Cases

Tighter identity verification often increases onboarding friction and operational overhead, so organisations must balance security assurance against developer velocity, emergency access, and regulatory deadlines. That tradeoff is real, but it does not remove accountability when controls are skipped.

One common edge case is delegated administration. A platform team may issue credentials on behalf of a business unit, but the business owner still remains accountable for accepting the risk if verification requirements are waived. Another is service-to-service access, where teams assume human-style proofing is irrelevant. That is only partly true: while the verification method differs, there still needs to be a trustworthy enrollment path, owner attestation, and revocation process. The Guide to the Secret Sprawl Challenge and Ultimate Guide to NHIs — Static vs Dynamic Secrets both reinforce that issuance without lifecycle control creates residual risk long after approval. Current guidance suggests that static credentials with weak verification should be treated as a high-risk exception, not a normal operating model.

For organisations operating across multiple clouds or regulated sectors, the question is rarely whether accountability exists. It is whether the approval chain is provable, whether exceptions are time-bound, and whether the organisation can demonstrate that issuance matched policy when the credential was created.

Related resources from NHI Mgmt Group

• Who is accountable when passwordless access, identity verification, and remote access controls fail to support compliance in mission-critical environments?
• How should organisations implement remote online notarization without weakening identity assurance or fraud controls?
• What breaks when organisations decentralise identity without strong verification and recovery controls?
• How should organisations implement document-free identity verification without weakening fraud controls or compliance checks?