The Zero-Trust Architecture Checklist for Cloud Migrations

The question that ends most cloud migration security reviews isn't 'is this encrypted?' It's 'if this one server is compromised, what else can it reach?' Most legacy architectures have no good answer, because the network was never designed to answer it.

Why Your VPN Threat Model Stopped Making Sense

Legacy security architecture draws a hard line between "inside the network" and "outside it," and trusts almost everything on the inside. That model made a certain kind of sense when your entire infrastructure lived in one data center behind one firewall. It stops making sense the moment you lift a workload into AWS or Azure, because now "inside the network" spans a data center, a VPC, and a set of laptops connecting from home Wi-Fi — and a VPN connection doesn't tell you anything about whether the device on the other end is compromised.

We see this most clearly during migrations, because migration forces a decision that's easy to defer indefinitely on-premise: does this specific service actually need to talk to that specific service, or has it just always been able to, by accident of network topology? Answering that question honestly is most of the work of a Zero-Trust migration.

The Checklist We Run Before Any Migration Goes Live

• Map every existing service-to-service connection before writing a single new firewall rule — you cannot safely restrict access you haven't first observed.
• Replace standing, long-lived credentials (static API keys, shared service accounts) with short-lived, identity-bound tokens issued per session.
• Enforce MFA on every human access path, including the break-glass admin account everyone forgets is still using a static password.
• Define explicit, per-service network policies before migration — the default posture after cutover should be deny, with access added back deliberately, not the other way around.
• Classify data sensitivity before deciding where a workload can live — not every service needs the same trust zone, and treating them identically is how a low-risk service ends up with access to a high-risk data store.
• Instrument logging before cutover, not after — you need a baseline of normal access patterns to have any chance of spotting abnormal ones later.

The Rollout Sequence That Survives Contact With Production

The single biggest reason Zero-Trust migrations get abandoned midway isn't technical difficulty — it's that an aggressive early segmentation change breaks something business-critical, and the resulting incident kills momentum for the rest of the programme. A conservative rollout sequence avoids this by proving the model works on a low-risk segment before touching anything that matters.

• Weeks 1–4: observe and map, without changing any access — build the baseline you'll need to know if a later change breaks something.
• Weeks 5–8: consolidate identity — one identity provider, MFA everywhere, no more standing shared credentials.
• Weeks 9–14: segment one well-understood, lower-risk service first, and watch it in production before expanding.
• Months 4–9: extend segmentation outward from the pilot toward your highest-value assets, using what the pilot's failure modes taught you.

What "Zero Trust" Isn't

It isn't a product you buy, even though plenty of vendors will sell it to you as one. An identity provider with strong MFA and a next-generation firewall are ingredients, not the finished architecture. Zero Trust is an operating principle — verify explicitly, grant the minimum access needed, assume breach — and it shows up as a hundred small configuration decisions across your identity provider, your network policies, and your application access controls, not as a single deployed tool.

If you take one thing from a migration security review, take this: the goal isn't a network where nothing can go wrong. It's a network where, when something does go wrong — and eventually something will — the blast radius is one service, not everything behind the firewall.