Collection-based access groups related secrets into a governed permission boundary. It allows teams to manage credentials by function or role rather than by individual request, which makes review and revocation much more tractable.
Expanded Definition
Collection-based access is a governance model for NHI permissions in which secrets are assigned to a managed collection that represents a function, workload class, or operating context. Rather than granting and reviewing each secret one by one, teams apply policy to the collection boundary and manage membership centrally. In practice, this makes the access model easier to audit, but only if the collection is tightly defined and kept aligned to actual runtime needs.
This concept is adjacent to RBAC and secret grouping, but it is not identical to either. RBAC assigns rights to roles; collection-based access groups credentials so that review, rotation, and revocation can happen at a higher level of abstraction. In mature environments, it often supports secrets managers, vault namespaces, or NHI governance workflows. Definitions vary across vendors, and no single standard governs this yet, so implementations should be evaluated by how well they enforce least privilege, separation of duties, and change control. For a broader NHI control context, see the OWASP Non-Human Identity Top 10 and Ultimate Guide to NHIs.
The most common misapplication is treating a collection as a convenience bucket, which occurs when unrelated secrets are bundled together to reduce administrative effort.
Examples and Use Cases
Implementing collection-based access rigorously often introduces design overhead, requiring organisations to weigh simpler day-to-day administration against the cost of maintaining precise boundaries.
- A payments platform groups all API keys for one microservice into a single collection so rotation and offboarding can happen without hunting through application code.
- A data engineering team places all secrets for a scheduled ETL pipeline into one governed boundary, then grants access only to the pipeline runner and break-glass operators.
- A platform security team maps collections to workload categories and uses review workflows to confirm each secret still belongs in that boundary, informed by guidance in the Ultimate Guide to NHIs — Key Challenges and Risks.
- An organisation with service-account sprawl uses collection membership to reduce review scope before applying policy updates across an entire application domain.
- Security engineers compare the collection structure against the OWASP Non-Human Identity Top 10 to ensure grouping does not hide excessive privileges or unmanaged secrets.
Why It Matters in NHI Security
Collection-based access matters because NHI risk scales faster than human identity risk, and security teams often lose control when secrets are managed as isolated exceptions instead of governed sets. NHIMG research shows that NHIs outnumber human identities by 25x to 50x in modern enterprises, which means fragmented secret handling quickly becomes unreviewable and difficult to revoke at incident speed. The same body of research also shows that 97% of NHIs carry excessive privileges, making collection design a direct control point for reducing blast radius. See the Ultimate Guide to NHIs for the underlying risk patterns.
When collections are well designed, they support faster offboarding, cleaner audits, and more reliable secret rotation. When they are poorly defined, they can create hidden privilege aggregation, especially if one collection spans unrelated environments or teams. That is why collection boundaries should be reviewed alongside policy inheritance, runtime ownership, and rotation cadence, not just storage location. Organisations typically encounter the need for collection-based access only after a secret leak, service-account compromise, or failed offboarding event, at which point the model 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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Addresses improper secret management and access grouping risks for NHIs. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control maps to collection-scoped NHI permissions. |
| NIST Zero Trust (SP 800-207) | PL-8 | Zero Trust requires explicit policy enforcement around each access boundary. |
Group secrets by governed boundary, then review, rotate, and revoke them as one controlled unit.
Related resources from NHI Mgmt Group
- What is the difference between role-based access and API key governance for NHI security?
- When does just-in-time access help most in DORA evidence collection?
- When does policy-based access control reduce risk for NHI environments?
- When does ticket-based access management become too slow for NHI governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
