Five observations recur in organizations that configure their systems by hand:
- Audit preparation takes weeks and produces screenshots.
- One engineer cannot be allowed to leave.
- The second environment took as long as the first.
- There is a policy nobody dares to touch.
- The last outage was explained as "someone changed something."
None of these is a people problem. They are one problem: the thing the business depends on — the configuration of its systems — is not written down anywhere the system itself can read.
The invoice was for hardware; the dependency was configuration
Before the cloud, every service a company ran sat behind its own firewall, and a few engineers wearing several hats carried the whole stack: network, perimeter, servers, applications, patching, endpoints, collaboration, governance, backups, service levels. Every one of those layers was a person configuring something, one setting at a time, and the sum of those settings was the business's technology.
The economics of that era were the economics of hardware. Capital tied up in servers, justified by depreciation schedules. More hardware bought to monitor the existing hardware. Tape libraries to hold what the servers produced. The invoices were for hardware.
The dependency was never on the hardware. It was on the thousands of individual decisions that turned generic equipment into this company's systems — and those lived in the engineers' memory, to be rebuilt from memory whenever a server was replaced.
The cloud changed exactly one thing in that picture: who owns the hardware. A provider buys the equipment, assumes the liability, and sells the outcome to many companies at once. Design, configuration, governance, and continuity stayed where they were. And they continued to be done the way they'd always been done — by a person, in a console, one click at a time.
The loop every engineer recognizes
Every platform ships with an administrative console, and for three decades the console has been the primary — usually the only — way systems get configured. To be fair to it: it is discoverable, it is immediate, and it needs nothing but a browser and a credential. For a small system with one administrator and a low rate of change, it is fine.
The trouble starts when the system grows, the rate of change rises, and more hands touch it. The figure below contrasts how change proceeds under manual configuration and under the alternative:
Under manual configuration, intent is discovered through breakage: configure, test, adjust, test again, and only then write down — from memory, by the person least motivated to do it — what was intended. The document describes the system at one moment and has no mechanism to stay true.
The costs that follow are real but scattered across budgets nobody adds up:
| Cost | How it is incurred |
|---|---|
| Rework | The same intent is rediscovered every time it is needed again — a second environment, a migration, a DR test. |
| Drift | The system stops matching its documentation, one undocumented click at a time. |
| Variance | Ten administrators produce ten dialects of the same policy. |
| Assessment | Every audit becomes a reconstruction: exports, screenshots, interviews, a narrative argued fresh each time. |
| Key-person risk | The reason a setting is the way it is leaves with the person who set it. |
| Recovery time | A rebuild is bounded by how fast people can click and how much they remember. |
| Scale penalty | Two environments cost twice the effort, twenty cost twenty times, with as many chances to diverge. |
None of these appears on an invoice. All of them are paid, every year, for as long as the platform exists.
What "as code" actually means
Infrastructure as code (IaC) is the practice of writing down the complete intended state of a system in structured text a machine can execute, and handing that text to a tool that makes the real system match. Identity as code is the same practice applied to an identity platform: users, groups, applications, access policies, authentication methods, and privileged roles described in files rather than clicked into a console.
The word "code" makes some leaders picture software development. It is closer to a specification. A file describing an access policy says: this policy applies to these people, for these applications, under these conditions, and requires this form of authentication. The important properties:
- Declarative. The file states the end state, not the steps. The tool works out what has to change — including nothing, if the system already matches.
- Versioned. Every change has an author, a date, a reason, and a reviewer. "Who changed this and why" is a lookup, not an investigation.
- Reviewable before it happens. The tool produces a plan — exactly what will be created, changed, or destroyed — before anything is touched.
- Repeatable. The same files build the same system in a test tenant, in production, or in a rebuilt environment after a disaster. The second copy costs almost nothing.
- Verifiable. Because the intended state is written down, a nightly comparison detects any drift and names the account that caused it.
The principle fits in one sentence: if a setting can be made in the console, it should be possible to make it in the tool — and if it can be made in the tool, it should be made there first.
This is not a workaround for the control frameworks regulated organizations are assessed against; it is the most direct way to satisfy them. NIST SP 800-53 wants a baseline configuration under configuration control (CM-2), reviewed changes (CM-3), restricted change access (CM-5), and documented settings (CM-6). The CIS Controls want a documented secure-configuration process (Control 4). Under declarative configuration, the repository is the baseline, the pull request is the change control, the pipeline identities are the access restriction, and the files are the documented settings. The audit evidence is a by-product of doing the work.
The math, with every variable named
"As code saves effort" is only useful to a leader if the variables are visible and can be replaced with the organization's own numbers. They are set out below.
| Symbol | Variable | How to estimate it |
|---|---|---|
| Y | Planning horizon, years | Expected life of the platform; usually 3–5 |
| N | Changes per year | Count last year's change records or console audit-log entries |
| Cp / Cc | Cost per change, manual / as code | Hours × loaded rate. Manual includes the second attempt; as-code includes review time |
| Rp / Rc | Incident cost per year | Probability × cost of a configuration-caused outage |
| Ap / Ac | Assessment cost per year | Hours preparing audit evidence, including reviewers |
| Kp / Kc | Knowledge-loss cost per year | Cost to re-learn the system after a departure, weighted by turnover |
| M | Environment multiplier | Tenants/regions holding the same configuration. Manual effort scales with M; as-code effort does not |
| U | Up-front investment | Design, initial code, pipeline, policy rules, training |
| P | Pipeline maintenance per year | A fraction of one engineer |
TCO (manual) = Y × [ N·Cp·M + Rp + Ap + Kp ]
TCO (declarative) = U + Y × [ N·Cc + Rc + Ac + Kc + P ]
Break-even = U ÷ (annual saving)
Two things carry the argument. The multiplier M only appears on the manual side — the same code serves every environment. And U is paid once, while every term in the manual bracket recurs annually for the life of the platform.
With illustrative inputs for a large organization (300 changes a year, two environments, a $350k investment), the as-code approach costs more in year one and roughly half as much over five:
The more useful test is the pessimistic one. A conservative case built to be unfavorable to as-code — lower change volume, smaller saving per change, a partial second environment, a higher investment — still breaks even inside five years, with five-year totals within two percent of each other. Even where the financial case is marginal, the organization obtains the documentation, controls, assurance, and rebuild capability at roughly no net cost.
The converse holds as well: a departmental application with one administrator and a dozen changes a year may never recover U. The equations should be run per platform and the answer accepted. The discipline is justified by the arithmetic.
An identity migration, two ways
The practice is currently designing an Okta to Microsoft Entra ID migration for a large regulated enterprise. The migration can be executed by hand in the Entra ID console or as code. Side by side:
| Step | Manual | As code |
|---|---|---|
| Inventory the source | Export reports, build spreadsheets. Accurate the day they are made; changes to Okta during the migration are discovered when something fails. | A read-only identity exports the entire Okta configuration nightly as code. Each night's export diffs against the last, so any change during the migration shows up for review. |
| Translate to the target | Recreate each app and policy by hand from the spreadsheet. Existing Entra config is left as found and worked around. | Import the existing tenant into code first (brownfield), rationalize it, then map every Okta object to an Entra definition, disposition, wave, and owner in a versioned catalog. |
| Build the write path | Admins with broad permissions change production directly. Approval is a ticket that may or may not get checked. | The pipeline is the only thing that changes the tenant: separate read/plan/apply identities with no stored secrets, policy checks that reject dangerous plans, a change-management gate, a rehearsal tenant, nightly drift detection. |
| Cut over and decommission | Apps move as owners become available. Rollback means someone remembers the old settings. | Risk-scored waves by business unit, each rehearsed and validated, with rollback as a configuration change. Okta assignments removed in a separate, later change. |
What each leaves behind is the point. Manual configuration, done well, leaves a working tenant, a spreadsheet that is already stale, and a group of people who know how it was built — a completed project. As code leaves a working tenant and an operating model: the tenant's definition in a repository with full history, a pipeline that is the only path of change, and nightly proof that the tenant matches its definition. The same pipeline governs every identity change after Okta is gone.
Where AI belongs, and why the order matters
The claim the whole argument rests on:
Declarative configuration is the precondition for governable AI-assisted operations.
A language model cannot safely operate a manually configured environment. There is no plan to review, no difference to approve, no rollback that is a file revert. It can safely participate in a declarative one, because every proposal it makes is a pull request through gates that were designed before it arrived.
That reframes the investment. The organization is not only buying auditability and a lower cost per change; it is building the only substrate on which AI operations can be governed. The order matters — as-code first, model second — and an organization that reverses it has given a system that can act the ability to act without a plan, a review, or a rollback.
The figure below shows where the model sits:
Humans set intent and approve. The model drafts, explains, and watches. The pipeline executes. The apply step has no model access, by design.
Three things to get right:
Grounded, not trained. The phrase usually heard is "train the model on our policies," and it describes the wrong mechanism. Fine-tuning bakes a snapshot of the environment into the model's weights — stale after the first drift, expensive to repeat, opaque to audit. The model should instead be given the current repository, inventory, logs, and tickets at the moment a question is asked, with every answer citing the file it came from. A fine-tuned model knows what the environment was; a grounded model reads what it is.
The model gets less than "read." "Give the AI access to Okta and Entra ID" implies live credentials with broad scopes. It does not need them. It reads the nightly inventory and the repository — not the live tenants — and holds no tenant credential at all. Its only write is a pull request from a bot identity that cannot merge. The blast radius of that design is a bad pull request that the plan, the policy rules, and a human reviewer see before it goes anywhere. The same placement neutralizes the real threat: tenant data (display names, group descriptions, ticket text) can contain text a model reads as an instruction — what OWASP classifies as indirect prompt injection. A model that can only propose cannot be induced to do more than propose.
The cost line, stated plainly. With a hosting-and-upkeep term added and the model re-run, the AI is roughly cost-neutral over five years at moderate change volumes. It earns its place in discovery — compressing a two-month read of policies, tickets, and sign-in logs into two weeks — and in keeping the repository explained, not in reducing the identity budget. A sponsor who expects it to cut the budget will be disappointed; one who expects it to compress discovery and keep every change explained will not.
What this asks of a leader
The engineers can build all of this. What they cannot do is decide that the organization will manage its systems this way. That decision has six parts:
- Adopt the policy, not the tool. The pipeline is how the platform changes. A console change becomes the documented exception with a reconciliation obligation, and the drift count is a management metric.
- Fund U against the break-even — computed with the organization's own inputs — and hold the program to it.
- Assign owners for the repository, the policy rules, and the change gate. Security should own the rules.
- Insist on the assessment benefit. The first time an auditor asks a question, the answer should be the repository. If it is a screenshot, the discipline has slipped.
- Expect the slowdown, and expect it to end. The first quarter is slower; the second is not. An organization that abandons the practice in the first quarter has paid U and received nothing.
- Adopt the placement rule before any model shows up: read-only against the inventory and repository, no tenant credential, output by pull request, hosting path chosen against stated criteria.
Three questions apply to any team proposing a new platform, a migration, or a rebuild:
- Where is the intended state written down?
- What is the only path by which it changes?
- How would the organization know if it stopped matching?
A team that can answer all three has an asset under management. A team that cannot has a console.
This post is condensed from a longer working paper, "Configuration as an Asset," which includes the full cost model with sensitivity analysis, the four design records for the migration, and the least-privilege design for the model identity. Organizations weighing an identity-platform migration, or deciding where AI belongs in their operations, can start a conversation.
Sources
- Forsgren, Humble, Kim. Accelerate: The Science of Lean Software and DevOps. IT Revolution Press, 2018.
- DORA. "DORA's software delivery performance metrics." dora.dev, 2026.
- NIST SP 800-53 Rev. 5, Configuration Management family (CM-2, CM-3, CM-5, CM-6).
- CIS Critical Security Controls v8.1, Control 4.
- OWASP Gen AI Security Project. "LLM01:2025 Prompt Injection."
- Microsoft Learn. "Conditional Access report-only mode"; "Manage emergency access admin accounts."
- HashiCorp. "What is Terraform."