Configuration as code means identity policy, entitlements, and access workflows are managed in version-controlled files instead of only through consoles. It turns access changes into reviewable, reversible change events and makes governance more consistent across applications and teams.
Expanded Definition
Configuration as code applies the infrastructure-as-code discipline to identity governance: access policies, entitlements, approval workflows, token scopes, and service-account settings are expressed in version-controlled files rather than maintained only in admin consoles. In NHI security, that matters because machine identities change quickly, and manual console edits create drift that is hard to audit. The approach supports peer review, change history, rollback, and repeatable deployment across environments, which makes it easier to align operational access with policy intent.
Definitions vary across vendors on the exact boundary between configuration as code, policy as code, and infrastructure as code. NHI Management Group treats the term as the broader operational pattern of managing identity-related controls through code so they can be tested, reviewed, and promoted like any other change. For general governance context, the NIST Cybersecurity Framework 2.0 reinforces the need for controlled change and asset governance, while configuration as code provides the implementation mechanism for NHI workflows. The most common misapplication is treating a script that creates access as configuration as code, which occurs when the file is not authoritative, reviewed, or tied to a controlled release process.
Examples and Use Cases
Implementing configuration as code rigorously often introduces review overhead and pipeline dependency, requiring organisations to weigh change speed against stronger governance and reproducibility.
- A platform team stores service-account roles in a repo so every RBAC change is code-reviewed before deployment to production.
- A security team encodes secret rotation schedules and approval gates in a workflow file, reducing ad hoc console-based exceptions.
- An engineering organisation uses code to define JIT access grants for agents, ensuring time-bound entitlements expire predictably after use.
- Identity administrators keep federation and token-lifetime settings in source control so changes can be traced to a specific pull request.
- Teams managing NHI sprawl use code to standardise onboarding and offboarding steps across clusters, clouds, and CI/CD systems, consistent with guidance in Ultimate Guide to NHIs and operational principles reflected in the NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Configuration as code reduces the hidden risk that accumulates when service accounts, API keys, and access policies are edited in isolation across teams. That is especially important because NHI Management Group reports that Ultimate Guide to NHIs found 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. When identity settings are defined as code, teams can scan them for overprivilege, validate them before merge, and reconstruct the exact state of access during an incident. It also helps organisations enforce repeatable controls across many applications, which is essential when NHIs outnumber human identities by 25x to 50x in modern enterprises.
Without this discipline, access drift tends to show up only after a secret leak, a failed audit, or an unexpected service-account compromise. At that point, configuration as code becomes operationally unavoidable because investigators need a reliable source of truth to determine what changed, when it changed, and who approved it.
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-01 | Covers identity governance drift and weak lifecycle controls for machine identities. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed consistently and reviewed as part of protective controls. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous control validation, which config-as-code helps operationalise. |
Express NHI access rules as code so policy can be enforced, tested, and changed without console drift.
