The intended shape and settings of a cloud resource as defined in code or policy. It is the reference point used to determine whether the real environment is correct. Without a desired configuration, teams lose a clean basis for detecting drift, enforcing standards, and controlling cost.
Expanded Definition
Desired configuration is the declared, authoritative state for a cloud resource, captured in code, policy, or both, and used as the benchmark for compliance, drift detection, and automated remediation. In NHI and IAM operations, it is not simply a document; it is the operational contract that says what a service account, secret store, workload identity, or policy attachment should look like at any moment.
Definitions vary across vendors on whether desired configuration includes runtime settings, policy intent, or only source-controlled declarations, but the security meaning remains consistent: the reference state must be explicit enough to compare against the live environment. This concept aligns closely with the control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, where configuration management supports baselines, change control, and continuous monitoring.
The most common misapplication is treating a manually edited console setting as the desired configuration, which occurs when teams lack version-controlled policy and assume the live state is the source of truth.
Examples and Use Cases
Implementing desired configuration rigorously often introduces process overhead, requiring organisations to weigh automation consistency against the cost of tighter change discipline and slower ad hoc edits.
- A Terraform or policy-as-code file defines which cloud roles a service account may assume, and any extra role attachment in the live account is flagged as drift.
- A secrets manager baseline requires rotation intervals, access policies, and approval workflow, preventing the kind of exposure seen in the Twitter Source Code Breach when sensitive credentials and access pathways were not governed tightly enough.
- An Kubernetes admission policy states that only signed workload identities may mount a credential volume, and anything else is rejected before deployment.
- A cloud security team compares the live state of IAM bindings against a declared baseline derived from NIST SP 800-53 Rev 5 Security and Privacy Controls to ensure least privilege.
- An operations team uses desired configuration to restore a compromised API gateway after unauthorised changes, returning it to the approved policy set.
In practice, desired configuration is most valuable when it covers identity-relevant settings such as token lifetimes, secret storage locations, and administrative grants, because these controls determine whether an NHI can be abused at scale.
Why It Matters in NHI Security
Desired configuration is the foundation for controlling NHI drift, and drift is where hidden privilege creep, exposed secrets, and unsafe automation usually begin. NHI environments are especially sensitive because machine identities are numerous, persistent, and often interconnected with CI/CD, orchestration, and cloud APIs. NHI Mgmt Group reports that 97% of NHIs carry excessive privileges, a figure that shows how quickly runtime reality can diverge from intended policy when there is no strong configuration baseline.
That gap matters because security teams cannot prove compliance or detect dangerous change without a trusted reference state. A desired configuration also supports offboarding, rotation, and incident recovery by making it clear what must be removed, restored, or reissued. It is the operational anchor for enforcing guardrails before a workload starts consuming tokens or reaching sensitive systems, and it complements broader controls described in Ultimate Guide to NHIs. Organisations typically encounter the impact of poor desired configuration only after a misconfiguration, exposure, or breach forces them to reconstruct what the environment was supposed to be, at which point the term 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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, 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 | Desired configuration establishes the approved baseline for NHI resources and drift detection. |
| NIST CSF 2.0 | CM-2 | Configuration baselines are central to managing intended system state and change control. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust depends on tightly controlled, verified system configuration and policy enforcement. |
| NIST SP 800-63 | Identity assurance depends on consistent control of authenticators and lifecycle state. | |
| OWASP Agentic AI Top 10 | A1 | Agentic systems need a defined runtime baseline to avoid unsafe autonomous changes. |
Treat credential and authenticator settings as governed configuration, not ad hoc operational changes.
Related resources from NHI Mgmt Group
- Why do configuration checks miss identity risk in SaaS environments?
- What is the difference between SaaS configuration and SaaS governance?
- What is the difference between sensitive environment variables and ordinary configuration values?
- What breaks when hardcoded credentials are left in code or configuration files?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
