Identity has become part of the infrastructure

For a long time, infrastructure was relatively easy to picture.

There was a network. There were switches, routers, servers, storage systems and endpoints. Applications sat somewhere on top and users connected to them.

If the network was available and the servers were running, a large part of the infrastructure conversation could be considered healthy.

That model has changed.

The network still matters. So do servers, endpoints, wireless, DNS, DHCP, storage and all of the other components that make modern organisations function. But another layer now sits across almost all of them.

Identity.

The question is no longer simply whether a device can reach a service.

It is increasingly:

Who is requesting access?

What device are they using?

Where are they connecting from?

What privilege do they have?

Should that privilege exist permanently?

What happens if their account is compromised?

How do we know that the person accessing a system is still authorised to do so?

These are security questions, but they are also infrastructure questions.

The traditional boundary has moved

In an older environment, network position often carried significant trust.

A device inside the organisation was treated differently from something outside it. Internal networks were separated into logical areas and firewalls controlled communication between them.

That architecture remains useful, but identity now provides another boundary.

A user may be physically connected to the organisation’s network but still have no legitimate reason to administer a cloud platform.

An administrator may have access to hundreds of systems, but that does not mean every administrative permission should remain active throughout the working day.

A contractor may require access to one application for three months but should not automatically inherit access to everything else associated with the organisation.

The security boundary therefore becomes more granular.

Instead of asking only whether a connection is allowed, organisations now need to decide whether a particular identity, using a particular device, under particular conditions, should be allowed to perform a particular action.

That changes infrastructure design.

Privilege is infrastructure

Administrative accounts are a good example.

It is easy to think of privileged access as an account-management issue.

Create the admin account. Give it the right permissions. Protect it with MFA.

But privilege affects resilience, recovery and operational risk.

If one highly privileged identity can administer email, identity platforms, endpoints, cloud resources and security tooling, compromise of that identity can become compromise of the organisation.

Equally, if administrators cannot gain access during a genuine emergency because access controls were designed without recovery in mind, security has created a different form of operational risk.

Good architecture has to consider both.

That means looking at separation of duties, privileged identity management, time-limited access, emergency access, logging, approval processes and the ability to recover when normal identity services are disrupted.

Those things are not additional paperwork around infrastructure.

They are part of the infrastructure.

Identity lifecycle matters as much as network lifecycle

Infrastructure teams are familiar with lifecycle management.

A switch is purchased, configured, deployed, monitored, maintained and eventually replaced.

Accounts should be treated with similar discipline.

An identity is created because somebody needs access.

Its permissions change as their responsibilities change.

Privileged access may be introduced later.

The user may move department.

They may become a contractor, employee or manager.

Eventually they leave.

At each stage, access needs to reflect reality.

The problem is that identity estates often accumulate.

Old groups remain.

Temporary permissions become permanent.

Dormant accounts survive migrations.

Former responsibilities remain attached to current users.

Service accounts become poorly understood dependencies that nobody wants to touch.

Individually, these can look small.

Collectively, they increase risk.

Identity therefore needs ownership and lifecycle thinking in exactly the same way as physical infrastructure.

The network still matters

None of this means the network has become irrelevant.

Quite the opposite.

Identity-aware security relies on dependable infrastructure underneath it.

Authentication still needs connectivity.

Cloud services still need DNS.

Endpoints still need secure configuration.

Wireless still needs appropriate segmentation.

Monitoring still needs useful data.

A modern organisation therefore cannot choose between infrastructure security and identity security.

It needs both.

The difference is that identity now shapes how infrastructure is consumed.

A different way of thinking

The biggest change for infrastructure professionals is therefore conceptual.

The question is no longer only:

How do I make this system available?

It becomes:

How do I make this system available to the right person, from the right context, with the right level of privilege, for the right amount of time?

That is a much more demanding question.

It requires networking, endpoint management, cloud architecture, authentication, governance and operational processes to work together.

Infrastructure has not disappeared into the cloud.

It has expanded.

Identity is now one of its most important components.