Identity is the control plane most infrastructure diagrams leave out

Infrastructure diagrams usually show networks, applications, databases and storage. The missing layer is often the one that decides who can change all of them.

A service can be online, healthy and fully replicated while the organisation has lost the ability to govern it.

The servers are running. The data is present. Monitoring reports no fault. But the only administrator account belongs to someone who has left, the recovery address points to an inaccessible mailbox, or privileged access depends on an identity platform that is itself unavailable.

Nothing in the application diagram appears broken.

Authority has broken.

Identity is frequently treated as a feature attached to infrastructure: single sign-on, a directory integration, perhaps multi-factor authentication. Operationally, it is much more than that. Identity determines who and what can act, which actions are permitted, how authority is recovered and what evidence remains afterward.

The central test

Identity is not an entry screen in front of infrastructure. It is the control plane that assigns, limits, recovers and records authority across the system.

Most diagrams begin after the decisive question

Architecture diagrams often begin with traffic.

A user reaches an application. The application calls an API. The API reads a database. Data moves to storage. Logs move to a monitoring platform.

The diagram may accurately describe technical flow while leaving out the authority behind every action.

Who created the user? Who approved the administrator role? Which identity can change network policy? Which service account can read the database? Who can rotate its credentials? Who can recover control when the primary identity system fails?

Without those answers, the diagram shows what the system does but not who can cause it to do something different.

Common mistake

Treating identity architecture as the presence of single sign-on.

Better framing

Map every route through which authority is granted, exercised, recovered, revoked and evidenced: for people, software and emergency operators.

Authentication is only the first decision

Authentication establishes that an identity has presented acceptable proof.

Infrastructure governance begins after that.

The system must determine which roles the identity receives, which resources those roles reach, how long authority lasts, who approved it and whether the actions can be attributed later.

A well-protected account with excessive privileges remains excessive. A strong login method does not correct a weak authorisation model.

This is why identity reviews need to separate several concerns:

• Identification: which person, workload or external organisation is represented.
• Authentication: how that identity proves itself.
• Authorisation: which actions it may perform.
• Lifecycle: how access is created, changed, suspended and removed.
• Recovery: how authority is regained after loss or failure.
• Evidence: how privileged actions are recorded and reviewed.

Collapsing these into “access management” hides the decisions that create operational risk.

Infrastructure has more machine identities than human ones

Human accounts receive most of the attention because people log in visibly.

Modern infrastructure also depends on service accounts, workload identities, API tokens, certificates, signing keys, deployment credentials, database users and automation roles.

These identities may have broader access and longer lifetimes than any individual administrator.

A deployment system may be able to replace production workloads. A backup process may read every database. A monitoring agent may collect sensitive operational data. A certificate authority may create credentials trusted across the estate.

When machine identities are treated as technical details, they accumulate quietly.

Tokens are copied into configuration files. Shared accounts survive several generations of applications. Certificates renew automatically until the renewal path fails. Nobody is certain which workload still needs a particular permission.

The identity architecture must therefore include both human and non-human authority.

                    ORGANISATIONAL AUTHORITY
                              |
          +-------------------+-------------------+
          v                   v                   v
    Human identities    Workload identities   Recovery identities
    staff - partners    services - jobs       break-glass - root
          |                   |                   |
          +-------------------+-------------------+
                              v
                    Infrastructure actions
                              |
                              v
                      Evidence and review

The recovery identities belong in the same model because they can override normal controls. They should not remain invisible merely because they are rarely used.

Recovery identity must survive identity failure

Identity recovery contains a difficult circular dependency.

Administrators often rely on the primary identity platform to access every other system. That is convenient during normal operation. It can be disastrous when the identity platform is the failed system.

If break-glass access requires the unavailable directory, it is not break-glass access.

If the recovery mailbox uses the same federation path, it is not independent.

If the only person who knows the root credential is the person the organisation cannot reach, the recovery process is personal rather than institutional.

Operational test

Assume the primary identity provider is unavailable. Identify exactly how authorised operators regain control of the identity platform, cloud accounts, core network, secrets and recovery systems.

A credible answer should identify more than a password location.

Who is permitted to initiate recovery? How is that person verified? Is more than one person required? Where are independent recovery factors held? How is use of the emergency path recorded and reviewed afterward?

Emergency access should be difficult enough to resist casual use and independent enough to survive the failure it is meant to address.

Identity boundaries define administrative blast radius

Network segmentation limits where traffic can move. Identity segmentation limits where authority can move.

A single highly privileged role reused across many environments can turn one compromised account into estate-wide administrative access. Shared automation credentials can give unrelated systems the same blast radius. A support supplier may receive persistent access when time-bound access would have been sufficient.

The useful question is not merely whether an identity is privileged.

It is privileged over what?

Production, recovery and development environments may need separate administrative boundaries. Backup deletion rights should not automatically accompany backup creation rights. The ability to deploy an application should not necessarily include the ability to change audit retention.

These separations can be inconvenient. That is partly their purpose. They prevent one mistake, credential or compromised process from exercising every form of authority at once.

Good identity design makes high-impact combinations explicit rather than accidental.

Departures test whether authority belongs to the organisation

A person leaving should not create uncertainty about who controls a system.

Yet departures often expose personal infrastructure: cloud accounts opened with private details, recovery codes stored on personal devices, repositories tied to individual ownership, service accounts named after employees and supplier relationships managed through private mailboxes.

Removing a departing person’s account is necessary but incomplete.

The organisation must understand which authority depended on that person, which machine credentials they controlled, which approvals they performed and which recovery paths refer to them.

This is particularly important for contractors and external collaborators. Access may be federated from another organisation whose lifecycle processes are invisible. A partner may disable an account before local teams have transferred ownership of the resources it created.

Identity transfer should therefore be part of role transfer.

A new operator needs more than equivalent permissions. They need responsibility for the credentials, approval paths, recovery material and evidence obligations attached to the role.

Evidence matters because authority is invisible after the fact

Infrastructure changes are often explained through system logs: a policy changed, a database was dropped, a secret was read.

Those events become governable only when they can be connected to accountable identities.

Shared administrator accounts weaken that connection. Long-lived tokens make it difficult to know which process acted. Logs stored inside the same environment may disappear with the system they are intended to explain.

An identity control plane should preserve evidence outside the immediate path of change.

That may include authentication events, privilege grants, role changes, emergency access, credential creation and high-impact administrative actions. Retention should reflect the organisation’s need to investigate and govern, not merely the platform’s default.

Evidence does not need to capture every harmless event forever.

It needs to answer the questions that matter:

Who had authority? Who changed it? Which identity performed the action? Was the action expected? Can the record survive failure or administrative interference?

A practical identity control-plane review

Area	Weak signal	Stronger evidence
Organisational authority	Administrator accounts exist	Named owners, role definitions, approval paths and periodic review
Human access	Staff use single sign-on	Role-based access with lifecycle rules and attributable actions
Workload access	Services have credentials	Scoped workload identities with ownership, expiry and rotation
Privilege	Multi-factor authentication is enabled	Separate high-impact roles with limited scope and controlled elevation
Recovery	Root credentials are stored somewhere	Tested independent recovery with named custodians and recorded use
External access	Contractors have named accounts	Time-bound access, sponsor ownership and explicit offboarding
Evidence	Login logs are available	Protected records of grants, elevation, emergency access and administrative change
Transfer	A replacement can receive the same role	Authority, recovery material and operating responsibility can all be reassigned

The purpose is not to create the largest possible identity programme.

It is to ensure that authority follows the organisation’s operating model rather than the history of who happened to configure each system.

Identity should be designed around failure, not convenience alone

Convenience matters. Operators need access that works. Applications need credentials that can be issued and rotated without constant manual intervention.

But an identity system designed only for the normal path can become the most concentrated dependency in the estate.

A stronger architecture asks what happens when:

• the primary identity provider is unavailable
• federation with a partner fails
• a privileged operator leaves unexpectedly
• a workload credential is exposed
• logs inside the production environment cannot be trusted
• the organisation must transfer administration to another team

The answer should not rely on perfect availability or perfect behaviour.

Identity becomes ownable when authority can be assigned deliberately, constrained visibly, recovered independently and transferred without losing accountability.

That is why it belongs at the centre of the infrastructure diagram, not at the edge as a login box.

One question for the next architecture review

Remove the application and network arrows from the diagram for a moment.

Then ask:

If the primary directory failed and the current administrators became unavailable, which organisational process would restore authority, and what evidence would prove that the right people, not merely the available people, took control?