Who is accountable for proving that access is still justified?

Why This Matters for Security Teams

Accountability for justification is not the same as ownership of the asset. In practice, IAM may provision access, IGA may run reviews, and application owners may approve business need, but the organisation still needs a defensible record showing why access remained valid at the time it was granted. That is especially important for NHIs, where privilege is often broad, persistent, and poorly observed. The Ultimate Guide to NHIs shows that 97% of NHIs carry excessive privileges, which makes evidence of ongoing justification a governance issue, not a clerical one. Auditors typically look for approval history, review outcomes, and business context, then compare them with current access state and actual use. The OWASP Non-Human Identity Top 10 reinforces that weak lifecycle controls and missing traceability are recurring failure patterns. In practice, many security teams encounter missing justification only after an audit, an incident review, or a production access dispute has already exposed the gap.

How It Works in Practice

Proving access is still justified requires a chain of evidence, not a single approval. IAM typically owns the technical enforcement record, IGA owns the review workflow, and the application or system owner owns the business decision. The governance function then needs to retain evidence that ties those layers together. For human access, this often means joiner-mover-leaver records, access review attestations, and ticketed approvals. For NHI access, the same logic applies, but the evidence must also show the purpose of the service account, the workload it supports, the scope of the secrets or tokens issued, and the renewal or rotation history.

• Capture the original justification, including the service, workload, or integration that required access.
• Record who approved it, when it was approved, and under what conditions it remains valid.
• Retain periodic review evidence showing whether the access is still needed, reduced, or removed.
• Link credentials or tokens to the owning workload so the justification can be tested against real use.
• Preserve revocation and rotation records so auditors can verify the access lifecycle, not just the current state.

This approach aligns with current guidance in NHI governance and Zero Trust, where access decisions are expected to be continuously defensible rather than assumed valid after the first approval. The 52 NHI Breaches Analysis is useful here because it shows how often breach paths involve forgotten service accounts, stale credentials, or access that was never formally revalidated. These controls tend to break down when ownership is fragmented across platforms, because no single team can produce a complete approval-to-use evidence trail.

Common Variations and Edge Cases

Tighter evidence requirements often increase operational overhead, so organisations must balance auditability against review fatigue and admin burden. That tradeoff is especially visible in high-change environments where access shifts quickly and manual attestation becomes stale almost as soon as it is completed. Current guidance suggests that the right answer is not to rely on annual reviews alone, but to combine periodic certification with event-driven revalidation when a workload changes, a token is reissued, or the business process ends.

There is no universal standard for this yet, but several edge cases recur. Shared service accounts can make ownership ambiguous unless the service catalogue records a single accountable business owner. Vendor-managed integrations may satisfy technical logging requirements while still failing if the customer cannot produce the vendor’s approval evidence. Emergency access is another common exception: the access may be justified in the moment, but the post-incident record must prove why it was necessary and who signed off on retention. Security teams should also treat dormant NHIs as a special case, because stale access often looks “approved” even after the system it supported has changed. In practice, this becomes visible only when review records are missing, not when access is first granted.

Related resources from NHI Mgmt Group

• Who is accountable when sustained infrastructure attacks disrupt access and availability?
• Who should be accountable when a compromised mailbox leads to fraud or access loss?
• Who is accountable when cloud access expires on paper but persists in practice?
• Who is accountable when an autonomous system acts on access decisions?