A user-facing location for storing unshared credentials inside the organisation vault while keeping default access limited to that user. It preserves privacy during normal use but allows organisational recovery when policy is enabled and the user departs. This design balances individual usability with enterprise control and continuity.
Expanded Definition
My Items is a user-visible vault area for credentials that remain private by default, yet can be recovered by the organisation when policy permits. In NHI and credential governance, this pattern is less about personal convenience than about controlled custody, auditability, and continuity across the credential lifecycle. It sits between individual usability and enterprise recovery requirements, and it is often implemented as part of a broader vaulting model rather than as a stand-alone security control.
Definitions vary across vendors on whether My Items is a true personal namespace, a soft ownership label, or a policy-driven access boundary. The operational meaning is the same: the user can store unshared secrets while the organisation retains a governed path to retrieve, rotate, or revoke them during offboarding or incident response. That makes it adjacent to NIST Cybersecurity Framework 2.0 governance and recovery expectations, but it is not equivalent to a personal password manager or informal archive.
The most common misapplication is treating My Items as private storage with no enterprise recovery process, which occurs when administrators enable user convenience without defining policy-based access, retention, and handoff rules.
Examples and Use Cases
Implementing My Items rigorously often introduces recovery and privacy tradeoffs, requiring organisations to weigh user autonomy against the cost of administrative oversight and policy enforcement.
- An engineer stores personal API keys in a vault namespace that is visible only to them during normal operations, while the security team retains policy-based recovery rights for departure handling.
- A platform team uses My Items for short-lived development secrets that should not be shared with peers, reducing accidental exposure while keeping offboarding manageable.
- An organisation maps My Items to documented lifecycle controls so that a manager or security administrator can recover credentials after a user exits, aligning with the recovery concerns described in Ultimate Guide to NHIs.
- A compliance team restricts use of My Items to approved vault workflows rather than email, chat, or local files, reflecting the broader identity hygiene concerns highlighted in NIST Cybersecurity Framework 2.0.
- A service owner separates shared team secrets from user-specific secrets so that personal custody does not create hidden operational dependencies during role changes.
Used well, My Items supports privacy without surrendering governance, but only when the organisation defines who can recover data, under what conditions, and how the action is logged.
Why It Matters in NHI Security
My Items matters because user-held credentials often become hidden operational dependencies. If the organisation cannot recover them, offboarding stalls, service continuity breaks, and orphaned access can persist after a person leaves. If recovery is too broad, privacy expectations erode and users may bypass the vault entirely. That tension is especially important in NHI programs, where secrets, tokens, and certificates must be controlled as part of the identity surface rather than treated as informal files.
NHI Mgmt Group reports that Ultimate Guide to NHIs found only 20% of organisations have formal processes for offboarding and revoking API keys, and 96% store secrets outside of secrets managers in vulnerable locations. My Items can reduce that exposure when it is used as a governed vault pattern rather than a shadow repository. It also supports zero-trust expectations because recovery, access review, and revocation remain enforceable even when the user is no longer present.
Organisations typically encounter the consequences only after a departure, incident, or vault misconfiguration, at which point My Items becomes operationally unavoidable to address.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret storage and recovery boundaries that My Items depends on. |
| NIST CSF 2.0 | PR.AC-1 | Access control and recovery governance align with private-by-default credential storage. |
| NIST Zero Trust (SP 800-207) | PA-3 | Zero Trust requires continuously enforceable access boundaries for stored credentials. |
| NIST SP 800-63 | Identity lifecycle assurance informs how recovered credentials remain trustworthy. | |
| CSA MAESTRO | Agentic and vault-mediated workflows need governed custody for user-specific secrets. |
Store user-held secrets in governed vault namespaces with defined recovery and audit controls.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
