How should security teams choose the first applications to protect when starting a Zero Trust segmentation programme?

Where to start the first ZT segmentation wave

The first applications should not be chosen for technical purity alone. Start where the organisation already has a strong reason to act, because that shortens decision cycles and makes the first deployment more likely to succeed. In practice, the best first targets are visible, business-critical systems with an owner who can move quickly and accept a controlled amount of change.

That usually means the programme begins with a narrow set of applications, not a broad platform cutover. If the initial scope is too large or politically difficult, segmentation becomes a design exercise instead of a delivery exercise. Choosing an early target that the business can feel quickly also helps create the confidence needed for later, harder rollout phases.

How to rank candidate applications for early segmentation

Three signals matter most: urgency, value, and willingness. Urgency comes from external pressure such as compliance, audit, or a recent incident. Value comes from protecting a system whose compromise would be highly visible or costly. Willingness comes from finding a team that will engage, test, and cooperate rather than treat segmentation as an imposed surprise.

A useful first-pass ranking is to prefer applications that sit near the centre of business operations, but are still manageable enough to segment without large redesign. That often includes crown jewel workloads, sensitive internal services, and applications with a clear boundary between trusted and untrusted traffic. The goal is to prove control over a meaningful slice of the environment, not to solve every segmentation challenge at once. For zero trust design principles, the NIST SP 800-207 Zero Trust Architecture remains the clearest external reference point, while NHIMG’s Ultimate Guide to NHIs, Standards is useful when segmentation also intersects with machine and workload access patterns.

Early adopters matter because segmentation changes how teams deploy, troubleshoot, and approve access. A team that is already open to measurement and iteration is more valuable than one with the theoretically perfect use case but no appetite for change. If the business owner can explain the need, sponsor the work, and tolerate an initial learning curve, the first rollout is much more likely to produce a repeatable pattern.

What makes a first application a good pilot

The best pilot has a defined traffic pattern, clear dependencies, and a stable owner. That makes it easier to understand what should be allowed, what should be denied, and where policy exceptions are actually justified. It also reduces the chance that segmentation breaks an application whose architecture is already poorly understood.

Good pilot candidates are often applications with known choke points, clear east-west communication paths, or a limited number of upstream and downstream systems. They should be important enough that the business notices the outcome, but not so fragile that one routing mistake or missing rule causes a major outage. A smaller but high-value pilot is usually better than a sprawling first scope that produces uncertainty instead of proof. The NIST Cybersecurity Framework 2.0 is a useful external lens for linking the pilot to broader governance, while NHIMG’s IAM and IGA Basics helps teams think clearly about ownership, authorization boundaries, and controlled access changes.

The most practical first application is often the one that gives you a reusable pattern for later rollouts. If the pilot forces the team to document dependencies, refine traffic rules, and define exception handling, it has delivered value even before the programme is widely expanded. That learning is the real asset of the first wave.

Practitioner Guidance

What to prioritise: Choose a system where the driver for change is already real, the owner is available, and the business can tolerate a measured implementation. If the first candidate needs prolonged persuasion, it is probably not the right first deployment.

What to verify: Confirm the application has a bounded set of flows, a known owner, and a sensible fallback if a policy change exposes hidden dependencies. If you cannot describe the allowed communications in plain language, you are not ready to segment it safely.

Common mistake: Starting with the most politically important platform or the most technically complex environment because it feels decisive. The better move is to start where the programme can prove value, improve the model, and earn trust for the next phase.

Practitioner takeaway: The first segmentation target should be chosen for momentum as much as protection, because early proof of value is what makes Zero Trust segmentation scale.

Related resources from NHI Mgmt Group

• How should security teams govern disconnected applications in a Zero Trust programme?
• How should security teams choose between micro-segmentation, software-defined perimeters, and identity governance when building Zero Trust Architecture?
• How should security teams use AI and machine learning to improve zero trust segmentation without breaking applications?
• How can security teams tell whether their identity programme is ready for zero trust?