Who is accountable for archived credentials in shared vaults?

Why This Matters for Security Teams

Accountability for archived credentials is easy to misunderstand because “archived” often sounds like “inactive,” but in shared vaults those are not the same thing. A user may archive an item in their own view while other authorised users still retain access, which means the credential can remain operational. That creates a governance gap if teams treat archiving as an access-control event rather than a user-interface action.

This is why shared vaults need explicit ownership, review cadence, and offboarding discipline. Credential lifecycle control belongs alongside vault policy, not inside a single user’s workflow. NIST’s control baseline for access governance emphasises that permissions and account state must be managed deliberately, not assumed from convenience features in the toolset, as reflected in the NIST SP 800-53 Rev 5 Security and Privacy Controls. NHIMG research shows the real-world consequence of weak lifecycle discipline: in the 2025 State of NHIs and Secrets in Cybersecurity, 91% of former employee tokens remained active after offboarding.

In practice, many security teams discover archived shared credentials only after an offboarding event, a breach review, or a failed access review exposes that the item was still reachable.

How It Works in Practice

In shared vaults, accountability is usually split between the person who archived the item, the vault owner, and the security or platform team that defines the control model. The key point is that archiving does not revoke access for everyone. It typically affects the archiver’s personal view or workflow state, while the underlying secret, token, or certificate may still be retrievable by other members of the shared space.

That is why teams should treat archiving as a convenience feature, not a control boundary. Stronger practice is to tie shared vault governance to ownership, periodic access review, and explicit revocation workflows. The OWASP Non-Human Identity Top 10 is especially relevant here because it frames secret lifecycle failures as a security issue, not just an administrative nuisance. For practitioners mapping the risk to NHI operations, NHIMG’s Guide to the Secret Sprawl Challenge highlights how duplicated and widely shared credentials become hard to govern once ownership is blurred.

• Assign a named owner for every shared vault item, not just the vault itself.
• Define who can archive, who can delete, and who can revoke access.
• Review shared membership on a schedule, especially after role changes and offboarding.
• Use archive status as a recordkeeping signal, not proof that a secret is no longer usable.

Where possible, align shared vaults with lifecycle automation so archived items trigger review tasks, rotation, or retirement rather than silent retention. These controls tend to break down in high-churn environments where many users share the same vault and access is granted informally, because no one can prove who still needs the secret.

Common Variations and Edge Cases

Tighter vault governance often increases operational overhead, requiring organisations to balance fast access for teams against the risk of stale or misowned credentials. That tradeoff becomes more visible in shared engineering environments, incident response vaults, and M&A integration projects, where multiple authorised users may need temporary visibility to the same secret.

Current guidance suggests treating these cases as exceptions with clear expiry and review dates, rather than allowing permanent shared access by default. A shared item archived by one user may still be active for others, and that is especially important for secrets stored in collaboration-heavy workflows or during transitions such as onboarding and offboarding. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here because it reinforces why long-lived static credentials are harder to govern than short-lived, purpose-bound alternatives. When archive state is used as a proxy for decommissioning, teams can miss the fact that the credential still exists and remains shareable in the vault.

Best practice is evolving toward stronger lifecycle separation: archive for personal workflow management, revoke for access removal, and rotate for credential hygiene. Where those actions are not clearly separated, accountability becomes ambiguous and shared vaults turn into hidden persistence layers.

Related resources from NHI Mgmt Group

• Who is accountable for deciding whether vaults should log users out instead of only locking them?
• Who is accountable when event registrations, demo accounts, or shared collaboration spaces expose sensitive access?
• How do organisations reduce the dwell time of exposed credentials at scale?
• How should organisations stop auto-sync from turning desktops into repositories of credentials?