A directory attribute that prevents an identity from being used in delegation flows. For machine accounts, it exists even when the administration console does not surface the checkbox, so validation must be performed directly against the object attributes rather than through the UI alone.
Expanded Definition
The Not Delegated Flag is a directory control that blocks an identity from participating in delegation pathways, which is especially important where service accounts, machine accounts, or privileged automation identities could otherwise be impersonated across systems. In practice, it is part of the broader NHI governance model used to reduce lateral movement and constrain how credentials can be used inside protocols that support delegated access. That makes it closely related to least privilege expectations in NIST Cybersecurity Framework 2.0, even though the flag itself is implemented at the directory-object level rather than as a policy abstraction.
Definitions vary across vendors and directory platforms, but the security intent is consistent: if an identity is not meant to act on behalf of another principal, it should be explicitly excluded from delegation. For NHIs, that distinction matters because tooling may hide the setting for machine accounts while still enforcing it in the underlying object attributes. The most common misapplication is assuming the flag is unset because the console does not show a checkbox, which occurs when administrators rely on UI state instead of querying the directory object directly.
Examples and Use Cases
Implementing the Not Delegated Flag rigorously often introduces operational friction, requiring organisations to weigh delegation flexibility against the security gain of reducing impersonation pathways.
- A service account used for application authentication is marked not delegated so it can connect to its target service, but cannot be used in Kerberos delegation chains.
- A machine account in an Active Directory environment has the attribute enforced even though the admin console does not expose an editable control, so validation must happen at the object level.
- During hardening reviews, identity teams compare delegation settings against the asset’s role to ensure only the minimum set of identities can participate in downstream impersonation.
- After reviewing exposure patterns described in the Ultimate Guide to NHIs, teams may add the flag to reduce the blast radius of overprivileged automation accounts.
- In incident response, analysts confirm whether a compromised identity could have been delegated elsewhere by checking the directory attribute directly rather than trusting the management UI.
Protocol behavior matters here, so teams often pair directory review with identity guidance from the Schneider Electric credentials breach case context and implementation references in NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
For NHI programs, the Not Delegated Flag is a practical control for limiting impersonation, constraining blast radius, and preventing privileged automation from being reused in ways that were never intended. This matters because NHIs are frequently overprivileged and difficult to inventory consistently, with NHI Mgmt Group reporting that 97% of NHIs carry excessive privileges and only 5.7% of organisations have full visibility into their service accounts. Those conditions make delegation review a high-value control, not a niche hardening detail.
When the flag is misunderstood, defenders can miss an attack path that only becomes visible after a credential is compromised and used laterally. That is why this setting should be checked alongside service account inventory, directory hardening, and post-incident validation. Organisations typically encounter the need to verify the Not Delegated Flag only after a delegation-enabled identity is abused for lateral movement, at which point the control 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-03 | Delegation constraints reduce abuse paths for overprivileged non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Access rights and remote use controls map to restricting delegated identity use. |
| NIST Zero Trust (SP 800-207) | Zero Trust limits implicit trust, including delegation-based impersonation paths. |
Verify NHI delegation settings and enforce object-level restrictions for identities that should not impersonate others.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
