Start by separating access based on trust and necessity. Review every shared vault and item, then remove or downgrade administrative permissions before copying or moving any data. Change passwords for accounts that may have been copied, and prioritize high-risk services such as email, banking, and Apple or Google accounts. The goal is to reduce standing access and prevent lockout, misuse, or silent account takeover.
How shared credentials become risky once a relationship changes
Shared passwords and shared vaults are usually safe only while both people still have the same expectations, device access, and trust. Once a relationship ends, the risk is not just intentional misuse. It also includes forgotten admin rights, synced vault apps, stored browser passwords, and copied secrets that can keep working after the split.
The practical problem is that a vault often contains more than one kind of access path. A password may be visible in the vault, cached on a phone, saved in a browser, or reused on an account that was never formally shared. If you do not inventory all of those paths, removing one person from the vault does not necessarily remove their effective access.
Shared vaults also create ambiguity about ownership. If both parties can edit, export, or auto-fill secrets, the safest assumption is that any secret already viewed may need to be treated as exposed. That is why the first move is to map access, then decide which items need rotation, replacement, or transfer to a single owner.
For broader context on credential sprawl and vault misconfiguration, The 2025 State of NHIs and Secrets in Cybersecurity reports that 73% of vaults are misconfigured and 96% of organisations store secrets outside secrets managers in vulnerable locations.
What to do first, and what actually matters most
Start with access, not cleanup. Remove or downgrade administrative permissions before moving data, because a person with edit or export rights can usually keep collecting secrets while you are still reorganising them. Then review every shared item and decide whether it can remain shared at all, or whether it should be moved to a vault owned by one person or one account.
High-risk accounts deserve priority rotation because they can expose everything else if compromised. Email, banking, password managers, Apple and Google accounts, and recovery channels are the usual first tier, because they often control resets for other services. If the former partner could have copied a password, viewed a recovery code, or approved a login, treat the account as needing a fresh secret even if there is no sign of abuse.
Do not rely on “remove access” alone when the same secret may have been reused elsewhere. The safest pattern is to rotate anything that may have been seen, then confirm that recovery methods, trusted devices, and secondary admins still belong only to the intended owner. That is the difference between removing convenience and actually restoring control.
For lifecycle and rotation guidance, NHI Lifecycle Management Guide and Guide to NHI Rotation Challenges both reinforce the operational point that access removal without rotation leaves residual risk.
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 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Shared passwords and vaults hinge on secrets exposure and rotation after access changes. |
| NHI-02 — Identity Lifecycle and Offboarding | Ending a relationship is an offboarding event for shared credentials and vault access. | |
| NHI-05 — Vaulting and Storage Security | The question centers on shared vaults and the misconfiguration risk around stored secrets. | |
| Recommendation — Rotate exposed secrets and remove shared access paths before reuse can persist. Revoke shared access and confirm all dependent accounts no longer trust the former holder. Restrict vault admin rights and move sensitive items into a single-owner vault model. | ||
| CIS Controls v8 | 5.3 — Manage Account Lifecycle | Shared accounts and former access must be removed or re-scoped when trust ends. |
| 6.3 — Data Protection and Credentials | Passwords, vault contents, and recovery factors require protection and rotation after exposure. | |
| Recommendation — Disable or reassign shared access immediately and verify all accounts have a current owner. Replace any credentials that may have been seen or copied during the shared period. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication and Access Control | The answer depends on removing standing access and revalidating who can still authenticate. |
| PR.DS — Data Security | Shared vault contents are sensitive data whose confidentiality depends on storage and access control. | |
| Recommendation — Reassess access rights and revoke authentication paths that no longer match current trust. Protect vault contents by reducing exposure, copying, and uncontrolled sharing. | ||
Practitioner Guidance
What to prioritise: Rotate the secrets that unlock the most other accounts first, then work outward to lower-value services. If a vault item was ever shared broadly, exported, or copied into notes or messages, assume it needs replacement rather than simple retention.
What to verify: Confirm that the former partner no longer has admin rights, recovery access, synced vault membership, browser access, or device trust. Also verify that no account still uses the same password across multiple services, because reused credentials can keep the old access path alive after the relationship has ended.
Common mistake: People often delete the vault share and stop there. That leaves the hardest problem untouched, which is that a previously visible secret may still authenticate successfully somewhere else.
Practitioner takeaway: The goal is not to “clean up” shared access, it is to re-establish single-owner control by removing hidden access paths and rotating anything that may already have been copied.
Related resources from NHI Mgmt Group
- How should security teams reduce the risk created by Azure Storage Accounts that allow Shared Key access by default?
- How should agencies secure CJIS access on shared workstations without slowing operations?
- How should organisations secure shared workstations without slowing production down?
- Who is accountable for third-party access when a vendor relationship ends?
