A permission model where each secret or credential is treated as a distinct resource with its own access rules. This matters because NIS2 expects organisations to govern access precisely enough to show the basis for each entitlement, rather than rely on broad shared access or informal trust.
Expanded Definition
Item-level Access Control treats each secret, token, API key, certificate, or similar credential as a separately governed resource. Rather than granting broad access to a vault, team, or environment, the policy binds each item to explicit read, use, rotate, revoke, and audit conditions. In NHI security, that distinction matters because the security boundary is often the credential itself, not the storage system that holds it.
This model aligns closely with the governance expectations reflected in the OWASP Non-Human Identity Top 10, where excessive privilege and weak secret handling are recurring failure modes. Definitions vary across vendors when “item-level” is used to describe vault ACLs, database permissions, or per-secret approvals, so practitioners should confirm whether the control applies to storage access, secret retrieval, or downstream secret use. Item-level controls are also a practical bridge to Zero Trust because they reduce implicit trust inside shared platforms and force decisioning around each credential instance.
The most common misapplication is treating folder-level or application-level permissions as item-level control, which occurs when every secret in a project inherits the same access path.
Examples and Use Cases
Implementing item-level access control rigorously often introduces administrative overhead, requiring organisations to weigh tighter containment against slower operations and more complex reviews.
- A CI/CD pipeline can retrieve only the deployment token for one service, while being denied access to all other secrets in the same vault.
- A break-glass administrator may be approved to view one production certificate during an outage, but not the broader credential set for that environment.
- Per-secret approval workflows can force a second reviewer before a high-risk API key is exposed to a third-party integration.
- Rotation policies can be attached to individual credentials so that high-value secrets expire faster than low-risk internal tokens.
- Audit logs can show exactly which agent accessed which secret, supporting evidence collection after an incident or compliance review.
NHIMG’s Ultimate Guide to NHIs notes that 96% of organisations store secrets outside of secrets managers in vulnerable locations, which makes item-level governance far harder to enforce in practice. For implementation patterns, the OWASP Non-Human Identity Top 10 is useful for mapping secret exposure to common NHI failure paths. In environments with many machine identities, item-level control is often the only way to prevent one compromised workflow from inheriting access to every credential in a shared system.
Why It Matters in NHI Security
Item-level Access Control is central to limiting blast radius when a single service account, workflow, or integration is compromised. Without it, one stolen credential often becomes a launch point for secret discovery, privilege escalation, and lateral movement across systems that were never intended to share trust. That risk is especially sharp in NHI estates where credentials outnumber human identities and are frequently reused across pipelines, automation tools, and third-party connections.
NHIMG research shows that 97% of NHIs carry excessive privileges, and that overbroad access is a persistent structural issue in real environments, as documented in the Ultimate Guide to NHIs – Key Challenges and Risks. Item-level controls help convert vague entitlement claims into auditable evidence, which is important when demonstrating least privilege under frameworks such as PCI DSS v4.0. They also support incident response by making it possible to revoke only the affected secret instead of disabling an entire workload.
Organisations typically encounter the operational necessity of item-level access control only after a secret leak or service compromise, at which point credential-specific containment becomes 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 address the attack surface, NIST CSF 2.0 set the technical controls, and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Item-level secret governance directly reduces excessive access and secret sprawl. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control requires resource-specific entitlement decisions. |
| PCI DSS v4.0 | 7.2 | PCI requires access to system components and data to be restricted by business need. |
Assign distinct permissions to each secret and review retrieval, rotation, and revocation paths.
