Introduction
Does connecting to the corporate network make a user trustworthy for every system they can reach? Zero Trust architecture addresses this question: access decisions should consider identity, device, the requested resource and risk conditions, beyond the user's network location.
NIST SP 800-207 establishes that network location or organisational ownership of a device should not, by themselves, confer implicit trust. The approach reorganises protection around users and resources.
The practical challenge is applying this principle without disrupting people's work. My recommendation is to begin with a critical business workflow and make its access decisions visible, justified and auditable.
Main Section
1. Define the workflow you want to protect
Start by identifying a priority application and its dependencies. A finance system, an administrative interface or an application holding sensitive documents may be suitable candidates.
For the selected system, establish:
- Which users and service accounts access it?
- What information does it process?
- Which other systems does it communicate with?
- Which business process would be affected by an access interruption?
- Who approves the access requirement?
This exercise also makes it easier to challenge whether an old permission is still necessary. An access list that has not been validated with the business owner is an incomplete basis for policy design.
2. Connect access decisions to identity and context
Alongside “Who is this user?”, consider which device they are using and the conditions surrounding the request.
An example policy might allow a particular user group to access only the relevant application, using managed devices that meet defined security requirements. Additional verification or access restrictions may be applied according to risk.
The frequency of verification and the way sessions are reassessed should reflect the resource's risk and the available technical capabilities. Unnecessary authentication prompts can make work more difficult.
The relationship between the components making policy decisions and those enforcing access should also be clear. Identity systems, device management and security telemetry need to work together.
3. Include privileged access and service identities
The scope should include administrators, automation and connections between applications, alongside employee accounts.
Review these areas in particular:
- Separate accounts for everyday work and administrative tasks.
- Privileges limited by task and duration.
- Service accounts with an identified owner and purpose.
- Access secrets that are stored securely and can be rotated when needed.
- Permissions updated when employees leave or change roles.
For example, an integration that only reads reports does not need permission to delete database records. Aligning permissions with business requirements limits the potential impact of account misuse.
4. Design segmentation around actual application flows
A network divided into VLANs can still allow unnecessarily broad access. Microsegmentation requires identifying the connections applications need and where the policies will be enforced.
For a web application, assess permissions between the front end, application server and database separately. Include backup, monitoring, DNS and administrative connections.
Observe the flows first, then validate their necessity with the application owner. Establish testing and rollback steps before narrowing permissions. A restrictive rule introduced with incomplete dependency information can interrupt a critical service.
5. Assess ZTNA within the wider architecture
Zero Trust Network Access (ZTNA) can provide application-specific access. When scoping a transition from VPN to ZTNA, examine application protocols, device support, administrative access and the user experience.
NIST SP 1800-35 provides implementation examples that combine different technologies. It is a useful reference for considering identity, networking, endpoint and monitoring capabilities together.
Direct integration may be impractical for some legacy applications. Options such as an access gateway or a controlled administrative jump server may be appropriate. The design should also address what happens when the identity provider or access components become unavailable, and how emergency access will be controlled and audited.
6. Work through a supplier access scenario
Consider a maintenance provider that needs to work on one specific server.
An example access design could include:
- An individually assigned account with an expiry date.
- Strong authentication.
- Access restricted to the approved destination and management protocol.
- Monitoring of session records and relevant security events.
- Removal of permissions when maintenance is complete.
If access to other servers or the backup infrastructure is unnecessary for the task, those paths remain closed. The authority granted then matches the boundaries of the maintenance assignment.
7. Manage the transition through a measurable pilot
An example starting plan, adaptable to the organisation's size:
- Days 1–30: Map one application's users, dependencies and existing access.
- Days 31–60: Trial policies with a small user group; monitor support requests and effects on the workflow.
- Days 61–90: Remove unnecessary permissions, review exceptions and use the results to decide whether to expand.
These periods are a planning example, rather than a standards requirement. Assess success through unnecessary access removed, accounts assigned an owner, time taken to revoke permissions, and users' ability to complete their work successfully.
Conclusion
Transitioning to Zero Trust requires a structure that can explain why access is granted and under which conditions it should continue. Identity, device, application and monitoring capabilities should serve this shared purpose.
To begin, choose a critical application and ask: “Who can access this resource today, for what reason and under which conditions?” Validate the answer, narrow unnecessary permissions and trial the selected policy with a small group.
The first tangible gain is knowing which access that application needs and being able to enforce those boundaries.