Managing identity as code for policies, secrets, and access

At a glance

What this is: This is an analysis of using Terraform to manage identity controls as code, with the key finding that versioned, reviewable configuration improves consistency, auditability, and recovery across identity operations.

Why it matters: It matters because IAM teams must govern human, NHI, and autonomous access with the same operational discipline, and code-managed identity can reduce drift, misconfiguration, and undocumented change.

By the numbers:

• Brex used Terraform to update 400 entitlement policies in just a few days.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read ConductorOne's guide to managing identity as code with Terraform

Context

Managing identity as code means treating users, groups, policies, entitlements, and access profiles like any other versioned configuration. In practice, that reduces reliance on dashboard clicks, makes changes reviewable before deployment, and gives teams a recoverable record of who changed what and when.

The IAM problem here is not just efficiency. When identity change is manual, drift accumulates, secrets age out unpredictably, and policy errors can silently expand access across human and non-human identities alike. Terraform shifts that burden into repeatable change control, which is why it matters for governance as much as operations.

Key questions

Q: How should IAM teams use Terraform to govern identity changes safely?

A: Use Terraform to define identity objects, approval rules, and access profiles in version-controlled code, then require peer review before changes are applied. That creates a repeatable change process, a recoverable history, and a clearer audit trail than manual console administration. It also reduces drift across environments and makes identity state easier to reconcile after incidents or audits.

Q: Why does managing identity as code help with NHI governance?

A: Non-human credentials and access policies often spread across systems, so manual administration leaves gaps that are hard to see and harder to reverse. Identity as code makes those controls explicit, reviewable, and repeatable. That matters because NHI risk is driven by drift, stale secrets, and unclear ownership, not just by malicious activity.

Q: What breaks when identity policies are updated manually instead of as code?

A: Manual updates increase the chance of misconfiguration, undocumented changes, and inconsistent access across environments. When a mistake happens, teams may not know what changed, who changed it, or how to restore the prior state. That creates both security risk and operational recovery risk, especially when access decisions affect production systems.

Q: How can teams tell whether identity as code is actually working?

A: Look for lower configuration drift, faster review cycles, fewer emergency access fixes, and a complete change history that matches the live environment. If identity changes still require ad hoc console edits or cannot be reproduced from code, the programme is only partially governed. The code should define the intended state, not just document it.

Technical breakdown

Identity configuration as code

Identity as code applies software delivery discipline to identity objects and policies. Instead of changing access controls directly in a console, teams define users, groups, entitlements, and approval rules in files that can be versioned, reviewed, and applied consistently. That makes identity state reproducible across environments and creates a history of change that manual administration usually lacks. The real architectural shift is not automation alone, but the move from mutable clicking to declarative control. Practical implication: make identity configuration part of the same Git-based change process used for other production controls.

Practical implication: make identity configuration part of the same Git-based change process used for other production controls.

Terraform-driven secret rotation and policy enforcement

The post links Terraform with two operational identity tasks: rotating integration credentials and enforcing access policies. Secrets such as API keys must be updated before expiry, and policy definitions must be consistent enough to avoid accidental privilege expansion. Infrastructure as code helps because the desired state is explicit, drift is easier to spot, and updates can be propagated predictably. The important design point is that the code does not remove trust from identity operations, it makes the trust boundary visible and reviewable. Practical implication: treat secret rotation and policy changes as controlled releases, not ad hoc admin tasks.

Practical implication: treat secret rotation and policy changes as controlled releases, not ad hoc admin tasks.

Access profiles and entitlement bundles

Access profiles bundle entitlements into reusable constructs that can be assigned to users or groups based on need. In code, that means the same profile can be provisioned consistently instead of recreated manually for each application or team. This matters because entitlement sprawl often starts when access is assembled one request at a time and never normalised. The Terraform model is useful here because it lets identity teams express the intended access pattern once, then govern changes through review and version control. Practical implication: standardise profile definitions before access sprawl becomes operational debt.

Practical implication: standardise profile definitions before access sprawl becomes operational debt.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity as code is a governance model, not just an automation layer. The value is not simply that Terraform reduces manual work. It changes identity management into a controlled change process with review, rollback, and history, which is what mature IAM programmes need when access decisions affect both human users and non-human identities. Practitioners should treat this as governance architecture, not convenience tooling.

Manual identity administration creates configuration debt that looks operational until it becomes security debt. When access policies, entitlements, and secret settings are changed by hand, the environment accumulates hidden drift that is difficult to reconstruct after an incident or audit. That is why code-managed identity matters: it makes state explicit and exposes error before deployment. The practical conclusion is that identity state should be as recoverable as application state.

Secret rotation and policy changes belong in the same controlled release pipeline. The post shows that identity administration often mixes two very different risks, expired credentials and misgranted access, but both are governance failures when handled informally. Managing them through code creates a single review surface for change, approval, and traceability. Practitioners should stop treating secret updates as a separate admin chore.

Access profiles are where identity standardisation meets entitlement sprawl. Bundled profiles can reduce one-off provisioning, but only if the underlying definitions are consistently governed and periodically reviewed. Otherwise, code simply makes bad access patterns repeatable at scale. The implication for IAM teams is to standardise profile design before scaling application onboarding or automatic access assignment.

NHI governance benefits directly from identity-as-code patterns, even when the article frames the problem as general IAM administration. Non-human credentials, policy bindings, and access bundles are especially sensitive to drift because they are often reused across systems and rarely revisited manually. The same code discipline that improves human identity change control also reduces hidden privilege growth in machine access. Practitioners should use this pattern to unify governance across identity types.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• Only 97% of NHIs carry excessive privileges, which is why code-defined access review matters before access sprawl becomes normalised.
• For the lifecycle side of the problem, see NHI Lifecycle Management Guide for provisioning, rotation, and offboarding discipline.

What this signals

Configuration drift is now an identity governance problem, not just an infrastructure problem. As more teams codify users, policies, and entitlements, the quality of the Git-based control plane becomes the real boundary between stable governance and silent privilege expansion. The practical signal is that identity teams should measure change provenance and drift the same way platform teams measure release integrity.

Identity as code can become a unifying control plane across human and machine access. That matters because the same failure patterns, stale permissions, unclear ownership, and unreviewed changes, show up in service accounts as well as human access. The programme implication is to align Git-based change control with the NIST Cybersecurity Framework 2.0 and the Ultimate Guide to NHIs rather than treating them as separate workstreams.

For practitioners

• Put identity changes under version control Store users, groups, policies, and access profiles in Git so reviewers can inspect every change before it reaches production and so rollback is possible when a bad change slips through.
• Automate secret rotation for integrations Use code-driven workflows to rotate API keys and secrets on a planned cadence, then update dependent settings before expiry so external integrations do not fail when credentials expire.
• Standardise entitlement bundles Define access profiles as reusable bundles with clear ownership and request rules, then manage changes through pull requests so entitlement sprawl does not grow through one-off manual grants.
• Audit policy drift against declared state Compare the live identity configuration with the code-defined desired state on a regular basis, and investigate any divergence in approvals, revocations, or entitlement mappings immediately.

Key takeaways

• Identity as code turns access governance into a reviewable, recoverable change process instead of a set of manual console actions.
• The control value is strongest where secret rotation, policy changes, and entitlement bundles can all be versioned and traced.
• IAM teams should use code to reduce drift and improve auditability before they scale access changes across humans and NHIs.

Key terms

• Identity as Code: An identity management approach that expresses users, groups, policies, entitlements, and access profiles in versioned configuration files. It brings software-style change control to IAM so teams can review, test, deploy, and recover identity state more consistently across environments.
• Access Profile: A reusable bundle of entitlements that can be assigned to a user or group based on role, team, or operational need. In practice, access profiles reduce one-off provisioning, but they require strict ownership and review or they quickly become a source of entitlement sprawl.
• Configuration Drift: The gap between the intended identity state and what is actually live in the environment. Drift often builds gradually through manual edits, emergency fixes, and inconsistent approvals, then becomes difficult to detect until it creates audit findings, privilege creep, or operational failures.
• Secret Rotation: The controlled replacement of credentials such as API keys or tokens before they expire or are exposed. For non-human identities, rotation is part of lifecycle governance because old secrets can remain valid long after the system that created them has changed.

Deepen your knowledge

Identity as code, secret rotation, and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are standardising access controls across human and non-human identities, it is worth exploring.

This post draws on content published by ConductorOne: Managing Identity as Code: How to Use Terraform with C1. Read the original.