Zero trust security: a practical roadmap beyond the network perimeter

Start with the principle and the resource

Zero trust is an approach to making access decisions, not a single appliance or licence. NIST describes an architecture in which trust is not granted implicitly solely because of network location or asset ownership. Authentication and authorisation are performed before a session to an enterprise resource is established. [1] Buying a product with a zero trust label does not demonstrate that these principles are in place.

Choose one important business resource for the first phase, such as a customer-record application or administrative interface. Identify its users, service accounts, data and dependencies. This makes the project concrete enough to test. Attempting to redesign every access path at once can obscure the workflows that require special handling.

Establish reliable identity and ownership

Create an inventory of human and machine identities that can reach the resource. Distinguish employees, contractors, administrators, integrations and unattended jobs. Assign an owner to each non-human identity and record why its access exists. An account with no accountable owner is difficult to review or remove safely.

Review joiner, mover and leaver processes. A change in role should trigger an access review, not simply add new permissions to old ones. Use authentication methods appropriate to the sensitivity and threat model, with stronger controls for privileged operations. Recovery and enrolment processes deserve attention because a strong login method can be undermined by a weak reset process.

Define access as a specific decision

Describe access in terms of identity, resource, permitted action and relevant context. A person who can view a customer record may not need to export the entire database. An integration that submits a transaction may not need administrative access to the application. Prefer permissions that correspond to a real task and can be explained to a reviewer.

Enforce these decisions at a trustworthy control point. Hiding a button in a browser is not sufficient authorisation for the underlying operation. Test direct requests as well as the normal interface. Document where network controls support the design, while recognising that access to a network segment should not automatically establish permission to every resource within it.

Introduce device requirements carefully

Determine which device properties are necessary for a particular operation and how they will be assessed. Managed software, supported operating systems and security tooling may be relevant inputs, but the organisation needs reliable evidence and an exception process. A posture check that frequently misclassifies legitimate devices can create pressure to bypass the control entirely.

Stage enforcement with a representative pilot group. Include remote workers, contractors and unusual but legitimate workflows. Record failed access attempts and distinguish policy problems from actual risk. Provide a supported route for remediation so users can restore compliant access without sending sensitive files to personal accounts or other informal workarounds.

Limit privileged and machine access

Review administrative paths separately from ordinary use. Reduce standing privileges where the environment supports a controlled alternative, and log privileged changes with enough context for investigation. Keep emergency access protected, monitored and periodically tested. An emergency mechanism that nobody can operate during an outage is not a dependable recovery plan.

For machine identities, scope credentials to the integration's function and store them in an appropriate secrets system. Plan rotation and revocation together with application owners. Expiring a credential without understanding its consumers can cause a service failure; leaving it indefinitely unmanaged creates a different risk. Both concerns belong in the implementation plan.

Measure coverage and improve deliberately

Track which valuable resources have explicit access policies, which identities have owners and which exceptions remain unresolved. Review denied requests and suspicious activity, but do not assume that collecting logs means someone is acting on them. Assign response responsibilities and test whether the evidence can support a useful investigation.

Evo's Cybersecurity service can help translate access requirements into a phased implementation. Bring an inventory of critical applications, identity systems and administrative routes. The first useful milestone is a tested policy for one meaningful resource, followed by an expansion plan based on evidence from the pilot.

Frequently asked questions