The Shift from Perimeter Thinking to Perpetual Verification
For years, organisations — particularly in the UK public sector — relied on a simple security model: build a wall, keep the bad actors out, and trust everyone inside. That model is now borderline dead. In 2026, Zero Trust isn’t a buzzword or an aspiration. It’s the baseline expectation for any organisation handling sensitive data, delivering citizen services, or operating at scale in the cloud.
At Mobilise, we’ve been at the coalface of this shift. Working alongside government departments, agencies, and public bodies migrating from legacy infrastructure to AWS and Azure, we’ve seen first-hand what it takes to move from theory to implementation. Zero Trust sounds straightforward in a whitepaper. In practice — mid-migration, with live services, constrained budgets, and teams still building cloud fluency — it’s a different challenge entirely.
This blog shares the practical lessons we’ve learned embedding Zero Trust principles into real public sector cloud migration programmes.
Why the Public Sector Can’t Afford to Wait
The UK public sector faces a unique combination of pressures. GovAssure assessments are tightening scrutiny on departments’ cyber resilience. The National Cyber Security Centre (NCSC) continues to raise the bar on expected security posture. And the migration away from platforms like GOV.UK PaaS has accelerated the need to adopt modern architectures and fast.
At the same time, public sector organisations carry a heavy legacy burden. Many still operate systems that were designed in a world where a VPN and a firewall constituted “security.” Moving these workloads to the cloud without rethinking access controls, identity management, and trust boundaries doesn’t solve the problem; it simply transplants it, kicking the can further and further down the road.
Zero Trust isn’t just a better security model for the public sector. It’s the only model that makes sense when your users are distributed nationally, your data is sensitive, and your infrastructure spans multiple cloud providers and on-premises environments.
The Five Pillars We Apply During Migration
When Mobilise delivers a cloud migration with Zero Trust at its core, we organise our approach around five practical pillars. These aren’t abstract principles, they are the areas where we’ve seen the biggest impact and the most common mistakes.
1. Identity Is the New Perimeter
The single most important shift in Zero Trust is treating identity — not the network — as the primary security boundary. Every user, every service account, every API call needs to be authenticated and authorised based on context: who they are, what device they’re using, where they’re connecting from, and what they’re trying to access.
In AWS, this means rigorous use of IAM policies, role-based access, and integration with identity providers like Entra ID or Okta. In Azure, it means Conditional Access policies, Privileged Identity Management (PIM), and enforcing MFA across the board — not just for admin accounts.
The most common mistake we see? Organisations that lift-and-shift their on-premises Active Directory straight into the cloud without rethinking group memberships, role assignments, or privilege levels. You end up with the same over-provisioned access model, just hosted somewhere more expensive.
2. Least Privilege — Enforced, Not Assumed
Every cloud migration should be an opportunity to reset permissions to their minimum viable level. In practice, this means auditing existing access before migration, designing new IAM structures from scratch rather than replicating legacy models, and using tools like AWS IAM Access Analyzer or Azure’s Access Reviews to continuously identify and revoke unnecessary permissions.
We’ve worked with public sector clients where service accounts had full administrator access “because it was easier during development” — and that access was never scaled back. In a Zero Trust model, temporary elevated access should be granted through just-in-time mechanisms and automatically revoked.
3. Micro segmentation of Workloads
Network-level trust boundaries remain important, but in a Zero Trust architecture they need to be much more granular. Rather than broad network zones that allow lateral movement, we design environments where each workload — each container, each serverless function, each database — has its own defined communication boundaries.
On AWS, this means Security Groups configured at the resource level, VPC endpoint policies, and using AWS PrivateLink to keep traffic off the public internet. On Azure, it means Network Security Groups, Azure Private Link, and Application Security Groups that map to workload identities rather than IP ranges.
The goal is simple: if one component is compromised, the attacker should find themselves in a locked room with no doors, not a corridor with open access to everything else.
4. Continuous Monitoring and Verification
Zero Trust doesn’t end at login. It requires continuous assessment of risk throughout a session. Is the user behaving normally? Has their device posture changed? Is this API call consistent with expected patterns?
We embed monitoring from day one using services like AWS CloudTrail, Amazon GuardDuty, Azure Sentinel, and Microsoft Defender for Cloud. But the key isn’t just turning on logging — it’s configuring meaningful alerts, building automated response playbooks, and ensuring that security teams can actually act on what they see.
For public sector clients operating under GovAssure, this continuous monitoring also serves a compliance purpose. Demonstrating that you can detect and respond to threats in near-real-time is increasingly a requirement, not a nice-to-have.
5. Secure-by-Default Landing Zones
A well-architected cloud landing zone is the foundation of Zero Trust in practice. Before any workload is migrated, the environment itself should enforce security guardrails: encryption at rest and in transit by default, logging enabled across all accounts, network egress restricted, and IAM boundaries in place.
At Mobilise, we build landing zones using Infrastructure as Code, typically Terraform or AWS CloudFormation, so that every security control is version-controlled, repeatable, and auditable. Or if there is an approved landing zone solution such as PALZ, then we use that rather than roll our own. This approach means that security isn’t a manual checklist applied after deployment; it’s baked into the infrastructure from the first line of code and in the case of PALZ gets you much closer to Zero trust from the first deployment.
Common Pitfalls We’ve Seen and How to Avoid Them
Even organisations with good intentions stumble on Zero Trust implementation. Here are the patterns we see most frequently.
Treating Zero Trust as a product purchase. No single vendor or tool delivers Zero Trust. It’s an architectural approach that spans identity, network, data, and application layers. Buying a “Zero Trust solution” without changing how you design and operate your environment is security theatre and often a costly mistake.
Boiling the ocean. Trying to implement Zero Trust across every system simultaneously leads to paralysis. We recommend starting with the highest-risk workloads — those handling personal data, financial information, or citizen-facing services — and expanding from there. Build confidence and capability incrementally. Rome wasn’t built in a day, but it nearly burned down in one.
Neglecting service accounts and machine identities. Most organisations focus Zero Trust efforts on human users and forget that service accounts, CI/CD pipelines, and automated processes also need the same rigour. In fact, these non-human identities are often the bigger risk, they’re persistent, over-privileged, and rarely reviewed.
Underinvesting in team capability. Technology alone doesn’t deliver Zero Trust. Your teams need to understand why they’re applying least privilege, how to configure identity policies correctly, and what to look for in monitoring dashboards. At Mobilise, enablement and knowledge transfer are central to every engagement precisely because security is only as strong as the team that maintains it.
Moving Forward
Zero Trust is not a destination — it’s an operating model. In 2026, the organisations that are most resilient are those that treat security as a continuous practice, not a project with a finish line.
For UK public sector bodies navigating cloud migration, the opportunity is significant. Moving to AWS or Azure isn’t just a chance to modernise infrastructure — it’s a chance to fundamentally reset your security posture around principles that are fit for the modern threat landscape.
At Mobilise, we’ve helped organisations like the College of Policing, Vale of Glamorgan Council, DVLA, and The National Archives to make that transition securely and at pace. If you’re planning or mid-way through a migration and want to ensure Zero Trust is embedded from the ground up, we’d welcome the conversatio
