Zero Trust rarely fails because no one understands the principle. The difficulties begin where an abstract goal needs to be translated into concrete applications, user groups, devices, policies, and operational roles.
Those who start too early with a product configuration often replicate the old network logic in a new platform. If you work too long on a complete target image, you create an architectural program with no visible effect. The effective path lies in between: a resilient discovery, a limited target image, a representative pilot and a handover of operations that is planned from the outset.
NIST describes Zero Trust as a focus on resources rather than implicit trust through network location or ownership. For a company, this means that it is not "in the internal network" that decides on access, but identity, device, application, context and policy.
Phase 1: Discovery starts with business
A good discovery is not a complete inventory of every port. It first identifies the business paths that will bring the greatest benefit to protect or simplify.
For each path, at least the following are recorded:
- User or service identity,
- device used and management status,
- Target application and business owner,
- today's access route,
- existing authentication,
- Data and protection needs,
- dependencies such as DNS, certificates or fixed IP addresses,
- known exceptions and operational issues.
Representative cases are particularly valuable: standard SaaS, private web application, legacy client, external service provider, administrative access, and a site with agentless devices.
Phase 2: The target image describes decisions
An architecture diagram alone is not enough. The target image must explain which decision will be made at which point.
For Zscaler environments, for example, this applies:
- Which transports run through ZIA?
- What private applications are delivered through ZPA?
- What device states affect access?
- Where is SSL/TLS inspected and where are there justified exceptions?
- Which source of identity provides groups and attributes?
- What locations or workloads need connectors?
- Which protocols or legacy systems need a transition path?
Each decision is given an owner, a justification and a test case. This makes the target image verifiable.
Phase 3: Policies by risk instead of history
Old rules are often organized by network segments, locations, or grown groups. A Zero Trust policy should move closer to application and purpose.
A workable policy model starts with a few clear classes:
- Standard access for managed users and devices,
- Increased requirements for sensitive applications,
- limited pathways for external partners,
- separate administrative access,
- Remediation for non-compliant devices,
- explicit handling of agentless systems.
Complexity is not caused by too few rules, but by too many unclear exceptions. That's why the policy owner and review date should already be fixed at the design stage.
Phase 4: The pilot must contain real friction
A pilot with only IT users and modern web applications proves little. It should contain typical problem areas without unnecessarily endangering the company.
A good pilot group covers different devices, locations, and applications. It tests positive and negative cases: allowed access, missing device health, expired certificate, unreachable connector, incorrect identity group, and justified exception.
Measuring points are:
- successful and failed accesses,
- additional latency and user experience,
- Time to diagnosis,
- the number and cause of necessary exceptions,
- Quality of logs and support information,
- Effort for rollback and retry.
Phase 5: Migration in waves
Zero Trust is rarely a big bang. NIST explicitly points out that classic perimeter and zero trust components can exist in parallel during a transition period.
Meaningful waves are based on risk and repeatability:
- Standard SaaS and clearly managed users,
- selected private applications,
- external and privileged access,
- Locations and agentless devices,
- Legacy and Special Protocols.
Each wave has entry criteria, test cases, fallback path, and proof of completion. This makes migration a controlled process instead of a series of spontaneous switches.
Phase 6: Operation is not a final chapter
Even during the pilot, it must be clear who will later qualify tickets, change policies, approve exceptions and escalate manufacturer cases.
The business transfer includes:
- Role and authorization concept,
- Runbooks for common malfunctions,
- Change and approval process,
- Monitoring and reporting,
- List of critical dependencies,
- outstanding risks and technical debt,
- regular review of exceptions and policies.
If these things are only created after the rollout, the project team will remain the actual operation permanently.
Three results that a good roadmap must deliver
A resilient Zero Trust roadmap doesn't just produce a sequence of products. It delivers:
A prioritized application and data flow picture. The company knows which paths are changed first and why.
A testable target architecture. Policies, identities, devices, connectors, and exceptions are mapped to specific decisions.
One operating model. Helpdesk, security, platform team and partners know tasks, approvals and escalations.
So Zero Trust doesn't stay on slides. It becomes an architecture that users can understand, teams can run and those responsible can develop.