TL;DR: Zero Trust often stalls when teams try to secure everything at once, but the Navy and DHS found progress by defining a protect surface and building controls around specific assets, according to Illumio. The shift matters because operational focus, not framework adoption, is what turns Zero Trust into measurable governance.
NHIMG editorial — based on content published by Illumio: How the U.S. Navy and Department of Homeland Security Made Zero Trust Work
Questions worth separating out
Q: How should security teams implement Zero Trust around critical business services?
A: Security teams should start by defining the smallest business service, data set, or application whose compromise would create real impact, then map every identity that can reach it.
Q: Why does Zero Trust fail when teams try to cover the whole enterprise at once?
A: Zero Trust fails when the scope is too large to support clear access rules, accurate telemetry, and consistent enforcement.
Q: What do security teams get wrong about Zero Trust policy design?
A: Teams often treat policy as a one-time configuration instead of an evolving decision model tied to actual use.
Practitioner guidance
- Map protect surfaces before expanding controls Start with the data, application, or service whose compromise would create mission failure, then list every human and non-human identity that needs access to it.
- Build policy around access conditions, not broad trust zones Write rules that reflect when access is valid, why it is needed, and which identity type is requesting it.
- Use telemetry to validate the policy model Compare real traffic and access patterns against the expected use of each protected asset, then adjust rules where behaviour and policy diverge.
What's in the full article
Illumio's full blog covers the operational detail this post intentionally leaves for the source:
- The webinar discussion of how the U.S. Navy and DHS translated Zero Trust principles into a repeatable operating model.
- The practical framing of protect surfaces and protect webs for complex government environments.
- The dialogue between John Kindervag and Don Yeske on what changes when teams stop measuring coverage and start measuring outcomes.
- The source article's examples of how policy, telemetry, and control placement work together in real deployments.
👉 Read Illumio's analysis of how the U.S. Navy and DHS made Zero Trust operational →
Zero Trust protect surfaces: what it means for IAM and security teams?
Explore further
Operational Zero Trust is really an identity scoping problem. The article shows that broad security frameworks fail when teams cannot define who or what should reach a protected asset. That is true for human access, but it becomes more urgent for NHIs, service accounts, and workload identities that often inherit access without a clear business owner. The field should treat scope definition as a governance control, not a documentation exercise. Practitioner conclusion: if the access boundary is vague, the Zero Trust programme is already underpowered.
A question worth separating out:
Q: Who is accountable for defining and maintaining a protect surface?
A: Accountability should sit with the business and security owners who understand the service's failure impact, while IAM and security architecture teams translate that impact into access controls. The protect surface is not just a technical boundary. It is a governance boundary that must stay current as services, identities, and dependencies change.
👉 Read our full editorial: Zero Trust becomes operational when teams define a protect surface