Identity Is the New Castle Walls: Machine Identity, Zero Trust, and How to Learn It in a Homelab

For twenty years, the castle walls were the network perimeter.

You built a wall, put a firewall on the gate, and ran a VPN drawbridge for the people who needed to cross it. Inside the wall was trusted. Outside was not. The whole model of enterprise security was a castle, and the job was guarding the doors.

That castle has no walls left.

Cloud moved your workloads off the estate. Remote work moved your people off it too. SaaS put half your business in other companies’ buildings. And now agents, software that acts on your behalf, are showing up inside the estate as a new kind of resident entirely. There is no “inside” left to stand in and feel safe.

The perimeter did not move. It dissolved.

What replaced the wall

When location stops meaning anything, the only thing left to make a decision on is identity. Every request, every service, every workload gets allowed or denied based on who or what it is, not where it is sitting. That is the entire premise of zero trust, and it is why the phrase “identity is the new perimeter” has been doing the rounds for a few years.

I would push it one step further. Identity is not just the new perimeter. It is the wall itself, in the full sense of the word: it is the thing you defend on, and it is the thing that decides whether you can be got at. It is the control plane for everything now.

If you want to see this idea in its homegrown form, the same principle runs through zero trust network access: access is granted to an authenticated identity, not to anyone who happens to be on the right subnet. The enterprise version has a bigger budget and an Entra tenant. The logic is identical.

The part most people have not caught up to: the wall got enormous

Here is the bit that changes the whole conversation, and it came home to me over a weekend doing something completely ordinary.

I was picking a secrets manager for a small platform. The free tier looked generous until I read the line that actually mattered: machine identities capped at five.

Five. That sounds like plenty, until you count what a machine identity actually is in 2026. Every service is one. Every container is one. Every scheduled job, every integration, every AI agent you stand up is one. Your human logins, the actual people, stay roughly flat. The machine identities multiply, and they multiply faster than your compute or your storage ever did.

So the thing you now defend on is not a handful of network entry points you can draw on a whiteboard. It is thousands of identities, most of them not human, and the count goes up every time someone ships a service or spins up an agent. The wall is no longer a thin line around the edge of the estate. It is vast, and most of it is machinery.

That is the real security story of the next few years. Not “how do we keep attackers out,” but “do we even know how many identities we have, what each one can do, and who is responsible for it.” (For a worked example of what happens when the answer is no, the reality is almost never a dramatic break-in. It is a valid credential used by the wrong hands. Attackers rarely hack in any more. They log in.)

What the frameworks actually say

This is where enterprise practice tends to drift away from enterprise guidance.

Both of Microsoft’s canonical frameworks are unambiguous on this point. The Cloud Adoption Framework treats identity as a centralised platform capability: it gets its own management group, its own subscription, its own platform team. The Well-Architected Framework’s security pillar says the same thing from the reliability and least-privilege angle. Identity is meant to be owned. Governed. Given a lifecycle, from the moment an identity is created to the moment it is retired.

If you have ever built an Azure landing zone, you have seen this in the reference architecture. Identity and access management sits in the platform layer, not the workload layer, on purpose.

Now here is what actually happens on the ground.

Delivery teams self-serve. They create their own app registrations, their own service principals, their own role assignments, because it is faster and because nobody explicitly said no. Every one of those is a machine identity that nobody central is tracking. Most are over-privileged, because “Contributor on the subscription” is quicker than working out the four permissions the app actually needs. A good number are orphaned the day the project ships and the person who made them moves on.

You cannot build a wall and then hand every team a shovel to cut their own gate through it. When identity is the perimeter, letting teams self-manage identity is everyone bringing their own door to the castle wall. It is not a bureaucratic preference to centralise it. It is the difference between one wall and fifty gates you did not know were there.

The same instinct shows up in the on-premises world too, which is why tiered administrative access and privileged identity exist: the point was never to make life hard, it was to make sure the powerful identities are the ones you can actually account for.

How to learn every principle of this in a homelab, for free

Here is the part I find genuinely exciting, and it is the whole reason I write this blog. Every principle above, the ones that get discussed in enterprise architecture reviews with serious money on the table, can be learned hands-on at home, for nothing.

You do not need a tenant with ten thousand users to understand centralised identity governance. You need a few services and the discipline to do it properly. That discipline is the transferable skill.

Start with a directory. Stand up an Active Directory domain in your lab. Create users, groups, and organisational units. Then govern them with Group Policy. This is where you feel, in your hands, the difference between “assign permissions to a person” and “assign them to a role and put the person in the role.” That single habit is most of enterprise RBAC.

Then touch the cloud version, free. The Entra ID (formerly Azure AD) free tier is enough to teach the model that matters. Create app registrations. Create service principals. Watch what happens to your identity count as you wire up two or three integrations. You will see the machine-identity explosion happen in miniature, on your own screen, and it teaches the lesson faster than any diagram: the non-human identities outgrow the human ones almost immediately. Conditional Access basics are learnable here too, and Conditional Access is the single most useful Entra concept to be able to talk about in an interview.

Centralise identity for your own services with an identity provider. This is the homelab move that turns the abstract lesson concrete. Instead of every service in your lab having its own separate login, put a self-hosted identity provider like Authentik in front of them and let it broker single sign-on. The moment you do this, you are living the Cloud Adoption Framework’s central lesson: identity is a platform capability that other things consume, not a thing each app manages for itself. You will never read “identity is a centralised platform capability” the same way again, because you will have built exactly that in your spare room.

Make access decisions on identity, not network location. Replace port forwarding and flat VPN access with an identity-aware mesh: Netbird if you want to self-host the control plane, Twingate if you want the managed version, or Tailscale as the zero-config option. Each of these grants access to an authenticated identity, not to a device that reached the right IP. That is zero trust, running in your house, on hardware you own. The homelab ZTNA walkthrough covers this end to end.

None of this costs more than the electricity, and all of it teaches the exact governance instinct that enterprises are short of. This is not a coincidence, it is the core of how I think about skills: your homelab already teaches you the security fundamentals that expensive certifications only describe. Machine identity governance is simply the next one up the ladder.

The bridge: same skill, different scale

This is the RTM thesis in a single topic. The enterprise architect governing ten thousand machine identities across a landing zone, and the homelabber putting Authentik in front of six services, are exercising the same muscle. One has a bigger budget and a compliance auditor. The underlying judgement, that identity is a platform you own rather than a thing you let every team invent for itself, is identical.

And it happens to be exactly the judgement the market is short on right now. As agents move from novelty to normal, every organisation is about to acquire a great many new non-human identities very quickly, and most of them have no plan for governing that growth. The person who has actually built centralised identity, even at homelab scale, understands the problem in their hands and not just on a slide. That is a career position worth being in. If you are thinking about it in those terms, the cloud-exit skillset piece makes the same argument for the infrastructure layer generally.

The question worth sitting with

So the real question was never which secrets manager, or which mesh VPN, or which identity provider. The tooling is downstream.

The question is who owns identity in your organisation. A platform team that governs it as the wall it now is, or whoever needed a service principal on a Tuesday and gave themselves Contributor to get the sprint done?

Have a look. You might be surprised how many doors are already cut into your wall.