An access control policy defines who can access which systems, under what conditions, and with what level of privilege. Under NIS2, it is not a paper exercise. It must be operationalised through review, enforcement, and evidence that access decisions reduce risk in practice.
Expanded Definition
An access control policy is the rule set that determines which non-human identities, human users, and automated agents can reach a system, API, dataset, or administrative function, and under what conditions. In NHI security, the policy must account for identity type, workload context, network path, privilege scope, and whether access is persistent or just-in-time. That makes it more than a role chart: it is a governance layer that should translate business intent into enforced permissions, review cadence, and revocation triggers.
Definitions vary across vendors when policies are blended with authentication, authorization, and entitlement governance, so NHI Management Group treats the term as the decision logic that governs access, not the credential itself. This distinction matters because a valid secret does not justify broad access, and a service account with standing privileges can still violate policy even when technically authenticated. Standards such as the NIST SP 800-53 Rev 5 Security and Privacy Controls and the OWASP Non-Human Identity Top 10 both reinforce least privilege, but neither replaces an operational policy tailored to NHI workflows.
The most common misapplication is treating the policy as a static document, which occurs when access rules are written once and never revalidated against changing workloads or privilege drift.
Examples and Use Cases
Implementing access control policy rigorously often introduces administrative overhead, requiring organisations to weigh reduced blast radius against the cost of review, automation, and exception handling.
- A CI/CD runner is allowed to deploy only to a single production namespace, with access granted through time-bound approval and removed after the job completes, consistent with the lifecycle practices described in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.
- An API key used by a data integration service can read one dataset but cannot export or delete records, aligning access scope to function rather than account ownership.
- A privileged automation account is denied direct console login and can operate only through an approved orchestration path, reducing abuse opportunities highlighted in the Top 10 NHI Issues.
- A third-party support bot receives access only during a maintenance window, with session logging and automatic revocation after the change ticket closes, reflecting the control intent in CIS Controls v8.
- A secrets manager policy blocks any service account from reading keys outside its environment, which is especially important when workloads span multi-team pipelines and federation boundaries.
For broader context on how unmanaged access turns into breach material, see the 52 NHI Breaches Analysis and the identity governance guidance in ISO/IEC 27001:2022 Information Security Management.
Why It Matters in NHI Security
Access control policy is where NHI governance becomes measurable. Without it, service accounts, API keys, certificates, and agent tool permissions tend to accumulate faster than teams can review them. That is one reason the Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, while only 5.7% of organisations have full visibility into their service accounts. Those figures are not abstract: they show that policy failure is usually a visibility failure first, then an incident response failure later.
When access control is weak, zero trust becomes rhetorical, not operational. The policy must support continuous verification, least privilege, and explicit revocation for NHI lifecycles, especially in environments shaped by NIST Cybersecurity Framework 2.0 and NHI-specific guidance from Ultimate Guide to NHIs — Regulatory and Audit Perspectives. The governance goal is not to deny all access, but to make every allowed action defensible, bounded, and reviewable.
Organisations typically encounter the practical cost of a weak access control policy only after a compromised secret, over-permissioned agent, or third-party account is used to move laterally, at which point the policy 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, NIST SP 800-53 Rev 5, 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-01 | Least privilege and service-account scoping are core NHI access control concerns. |
| NIST CSF 2.0 | PR.AC | Access control policy operationalizes identity and privilege management outcomes. |
| NIST SP 800-53 Rev 5 | AC-2 | Account management control supports policy-driven provisioning, review, and removal of access. |
| NIST Zero Trust (SP 800-207) | AC-3 | Zero Trust relies on continuous authorization decisions, not static trust grants. |
| NIST SP 800-63 | AAL2 | Assurance level concepts help bound when an identity can be trusted for access. |
Define, enforce, and monitor access rules so every identity is authorized for a specific business need.
