Restricted data is the most sensitive classification and demands the highest level of protection. It often includes PII, PHI, critical intellectual property, and classified information. Organisations typically apply strict access controls, multi-layered security, and regular audits because disclosure can create severe operational, legal, and personal harm.
Expanded Definition
Restricted data is not just “sensitive information.” In NHI security and access governance, the term usually means data whose disclosure would create exceptional harm, so controls must account for both the data itself and every identity that can reach it. In practice, that includes regulated personal data, protected health information, high-value intellectual property, security telemetry, and classified or export-controlled material. Usage in the industry is still evolving, and definitions vary across vendors, but the operational pattern is consistent: restricted data demands stronger authentication, tighter authorization, stronger encryption, and more intensive logging than ordinary confidential data. That aligns closely with the protection intent described in NIST Cybersecurity Framework 2.0, especially where access control and data protection intersect. In NHI environments, the critical issue is not only who can read the data, but which service accounts, API keys, and agents can copy, transform, or exfiltrate it through automation paths. The most common misapplication is labeling data as restricted without binding that classification to actual machine identities and execution paths, which occurs when data governance is disconnected from NHI access review.
Examples and Use Cases
Implementing restricted-data controls rigorously often introduces friction for automation, requiring organisations to balance rapid service-to-service access against stricter approval, segmentation, and audit requirements.
- A payment platform classifies cardholder records and token vault exports as restricted data, then limits access to only the narrowest set of production service accounts.
- A healthcare workflow routes PHI through a signed API path and monitors every retrieval by NHIs, rather than allowing broad repository or queue access.
- An engineering team protects source code containing proprietary algorithms as restricted data because CI/CD bots and build agents can leak it faster than human users.
- A defence contractor treats design drawings and classified attachments as restricted data, pairing role approval with short-lived credentials and continuous audit trails.
- An enterprise uses the classification to decide which NHIs can call a secrets manager and which must be denied by default, consistent with guidance in the Ultimate Guide to NHIs — Key Research and Survey Results.
These patterns are reinforced by broader identity and data-control guidance in the NIST Cybersecurity Framework 2.0, especially where least privilege and monitoring are expected.
Why It Matters in NHI Security
Restricted data becomes a governance issue when non-human identities are allowed to touch it without the same discipline applied to human access. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges, which means restricted data is often exposed through machine pathways that teams do not fully inventory. The risk is amplified because secrets and tokens can be copied into logs, pipelines, caches, and third-party integrations faster than a human reviewer can intervene. That is why restricted-data handling must be paired with secret hygiene, workload identity controls, and continuous entitlement review, not treated as a static classification label. The NHI management implications described in the Ultimate Guide to NHIs — Key Research and Survey Results are especially relevant when data is accessed by automation at scale. Organisations typically encounter restricted-data exposure only after a breach, audit finding, or incident response review, at which point the classification 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 Zero Trust (SP 800-207), NIST AI RMF 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 | Restricted data exposure often stems from secret sprawl and over-permissioned NHIs. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access management are core to protecting highly sensitive data. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires data access decisions based on explicit verification, not network trust. |
| NIST AI RMF | AI risk management highlights protection of sensitive data used or produced by automated systems. | |
| NIST SP 800-63 | IAL2 | Identity assurance concepts help define how strongly access to sensitive resources must be controlled. |
Require strong identity proofing and equivalent assurance for humans approving NHI access to restricted data.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
