Declarative Access

The Factors of Declarative IAM

Introduction

Identity and access management runs on a workflow designed for physical key cards: request, approve, provision. Each step manual. Each step independent. Each step a place where information is lost, delayed, or forgotten. Onboarding takes days. Offboarding is incomplete, and slow, because no one can say with confidence what access a person actually has. The organization must search before it can act. Access accumulates. Audits are archaeology. And the people responsible are trapped in a loop of tickets and spreadsheets that scales linearly with headcount and exponentially with systems.

Infrastructure went through this crisis and solved it. Infrastructure as Code replaced manual provisioning with declarative definitions: describe the desired state, let automation achieve it. The result was reliability, repeatability, and auditability at scale. Identity has not had this transformation. Declarative Access is the argument that it should, and a set of principles for how.

Decisions, not technology. Infrastructure as Code was never about servers or networks. It was about encoding human decisions (what should exist, how it should be configured, who approved the change) in a form that is reviewable, repeatable, and auditable. The technology was the medium, not the message. The message was: decisions deserve to be expressed with the same rigor we apply to the systems they govern. Access as Code takes this principle to its natural domain. Access decisions are people decisions: who is trusted, with what scope, for how long, under whose authority. These are consequential decisions an organization makes about its digital assets. If a server's network configuration deserves declarative rigor, a person's access to production certainly does.

Every ad-hoc permission grant, every unrevoked temporary access, every system provisioned outside a documented process: these are shortcuts that accumulate like technical debt. The interest is paid in audit hours, incident response time, onboarding delays, and compliance overhead. Few measure this debt because it is distributed across teams and budgets. But it compounds with each hire and each new system. These factors describe how to stop borrowing and start paying it down.

These factors are tool-agnostic. They do not prescribe a specific platform, language, or vendor. They describe the properties that an identity management system must have to be reliable, auditable, and humane at scale.

The analogy to infrastructure is deliberate and largely sound, but it is not perfect. Revoking a server's network access does not lock a human out of their benefits portal. Identity changes carry human urgency and legal weight that infrastructure changes do not. Where the analogy holds, we use it. Where it breaks, we say so.

The Factors

I

Declarative Access

Define who should have access to what. Let automation make it so.

 II

Single Source of Truth

One place to look. One place to change. One place to trust.

 III

Separation of Definition and Assignment

Those who design the roles are not those who fill them.

 IV

Composable Roles

Build access from small, reusable, well-understood blocks.

 V

Fan-Out Provisioning

Define once. Apply everywhere.

 VI

Informed Approval

A human decides: with full visibility. A machine executes: precisely.

 VII

Lifecycle Management

Onboarding adds. Offboarding removes. Both are a single change with complete effect.

 VIII

Ephemeral Privilege

Standing access is a liability. Time-bound access is a design choice.

 IX

Continuous Reconciliation

Detect deviation. Correct it. Least privilege is the result.

 X

Inherent Audit Trail

The history of access is not a report to generate. It is a record that already exists.

What This Doesn't Solve

No framework covers all problems. The following are adjacent to declarative access but separate concerns, each with its own body of practice:

Secrets management: a natural extension. Tools like HashiCorp Vault or AWS Secrets Manager store and broker credentials: database passwords, API keys, certificates. These systems solve a different problem than identity management, but the principles here apply directly to who can access which secrets and under what conditions. An application team that manages external API credentials for their service does not need to see the database credentials that same service uses at runtime. Those are machine secrets, scoped to the runtime environment, not to the humans who deploy it. Declarative access defines the boundary: which roles can retrieve which classes of secret, with what temporal constraints, through what approval path. Vault enforces it at the machine layer. The access model and the secrets broker are complementary: one says who can ask for what, the other says whether the ask is valid and hands over the credential.

Device trust and endpoint security. Whether a person's laptop is managed, encrypted, and compliant is an orthogonal concern to what permissions they hold. A person with correct permissions on a compromised device is still a risk. Device trust is a precondition for access decisions, not part of the access model itself.

Network access and zero trust. Service-to-service communication, network segmentation, and mTLS identity are related but distinct. A service mesh identity is not a human identity. The principles here apply to people and their access to systems, not to systems and their access to each other. That said, user-level network controls like VPN access, wireless certificates, and remote desktop permissions fit naturally as downstream targets. When a person is removed from the configuration, revoking their VPN certificate and disconnecting active sessions is just another fan-out operation, no different from removing them from a SaaS application.

Physical access. Badge readers, door controllers, and building management systems that expose an API are fan-out targets like any other. Provisioning a badge when someone joins and revoking it when they leave is the same operation as provisioning and revoking a SaaS account. Physical keys (non-rotating, non-revocable, untraceable tokens that grant access to real spaces) are a liability in the same class as standing SSH keys or hardcoded credentials. The principles apply: if it doesn't rotate, if it can't be revoked from a single change, it's a problem the model is designed to solve.

These are not weaknesses of the model. They are its boundaries. An organization that adopts declarative access will still need solutions for these domains. The value of the framework is that it reduces the identity problem to something tractable, not that it removes all security concerns.

Getting There

The principles above describe a target state. Many organizations reading this will be starting from a different place: dozens of systems with inconsistent access models, years of accumulated permissions, and no single inventory of what exists. The gap between here and there is the hardest part of the project. The following is a rough sketch of how the transition typically works, not a rigid methodology.

Discover

Before anything can be declared, it must be understood. The first phase is discovery: inventory each system that manages identity or access, catalog the permissions models each one uses, and map who currently has access to what. This is archaeology, and it is necessary. The output of this phase is a rough baseline of reality, not a clean model. It will be incomplete. That is acceptable.

Import as Baseline

Take the current state, messy and imperfect as it is, and express it in the declarative configuration format. Do not try to clean it up. Do not try to idealize it. The initial configuration is a photograph of the current state, not a vision of the desired one. Commit it. This baseline is the starting point for all future improvement.

Reconcile in Observation Mode

Enable continuous reconciliation in observation-only mode: detect drift and report it, but do not correct it automatically. This teaches the organization what drift looks like, how often it occurs, and which systems are the worst offenders. It also validates that the integrations work before they start making changes. Run in this mode until the team is confident in the data.

Tighten to Enforcement

Once the reconciliation data is trusted, begin enabling automatic correction: first for low-risk systems, then progressively for more sensitive ones. Each step tightens the loop. Each step reduces the window between drift and correction.

Iterate on the Model

With enforcement active, the model itself can be improved: consolidating redundant roles, introducing composable building blocks, adding temporal constraints, separating definition from assignment. The model evolves inside the same system that enforces it. Each improvement is a reviewed, approved, versioned change.

Many organizations will adopt declarative access for some systems before others. This works. The framework degrades gracefully: a person's access is fully managed in the systems that are integrated and unmanaged in the ones that aren't. The configuration can express both states. The audit trail reflects both. There is no requirement to integrate all systems simultaneously: only a commitment to expand coverage over time.

The goal is not perfection on day one. The goal is a system that improves monotonically: better tomorrow than today, day by day, without backsliding.

What This Replaces

The traditional model of identity management was designed for a world of single systems and physical access. It has been stretched far beyond its design limits, and the consequences are visible in organizations that operate at scale:

Access requests take days because they pass through queues of humans who interpret, approve, and execute them manually. Onboarding is slow and inconsistent because each system is provisioned independently. Offboarding is incomplete because there is no single place that knows each system a person could access. Permissions accumulate over years because revocation depends on someone remembering. Audits are painful because the evidence is scattered across dozens of admin consoles. Compliance is performative because the documentation diverges from reality the moment it is written.

Declarative Access replaces this with a model where identity is defined in code, changes are reviewed and approved before they take effect, automation handles execution across all systems, and the complete history is embedded in the workflow.

The principles in this document are not theoretical. They are drawn from the same practices that transformed infrastructure management from a manual, error-prone craft into a reliable, auditable engineering discipline. The tools and platforms are different. The principles are the same.

Access is a broad category of organizational technical debt that few measure. The interest is paid in audits, incidents, and lost time. The principal grows with each hire, each new system, each shortcut taken under pressure. These factors describe how to stop accumulating it.