Zero Trust Security: Principles and a Practical Starting Point

A laptop connects to the office network. Does that mean its user should be allowed into the payroll system, the production database and the backup console? Zero Trust starts by rejecting that shortcut. Being inside a network is not enough to establish permission to use a resource.

This is an approach to designing access, not a single appliance or a switch that makes an organisation secure. It is particularly useful when employees, applications and data are spread across offices, cloud services and remote devices.

Make access decisions about the resource

NIST SP 800-207 describes a resource-focused architecture that does not grant implicit trust solely because of network location or device ownership. Authentication establishes an identity; authorisation determines what that identity may do. A successful sign-in to one service is not automatic permission to access everything else.

For example, allowing a support employee to view a customer's ticket does not require permission to export the entire customer database. The resource, requested action and business need should shape the decision.

Identity, device condition and limited permissions

A practical policy can consider the account, device condition and risk of the requested action. Strong authentication helps establish who is connecting. Device management can supply information such as whether a laptop meets the organisation's security requirements. Neither signal should stand alone as a universal pass.

Least privilege means granting the access required for a task, with an appropriate duration. Administrators can use separate privileged identities and temporary elevation instead of leaving every daily account permanently powerful. Reassessing access as conditions change does not mean asking a user to type a password for every click.

Microsoft’s Zero Trust overview connects explicit verification and limited privileges with an assumption that a compromise may already exist. Segmentation and monitoring help limit what a compromised account or workload can reach. Firewalls still have a role; calling a system Zero Trust does not replace network controls or incident response.

A small pilot: access to a publishing dashboard

Consider this example policy for a team publishing articles:

• Writers can edit their own drafts but cannot manage accounts.
• Editors can approve content; publishing access is separate from server administration.
• Administrative changes require a stronger sign-in method and an approved device.
• A departing contractor's access is removed from both the identity system and the application.
• Rejected requests record which rule prevented access, so the team can investigate mistakes.

This is an illustrative design, not a universal permission model. A two-person team may need different roles, and an older application may not support all of these controls. Mapping those limitations is part of the work.

Check the policy before expanding it

Start with one application, list its users and service accounts, and document which actions each needs. Test legitimate work as well as denied access: can an editor still publish, can a disabled account reconnect, and can a writer reach an administrative endpoint directly?

Record the exceptions, their owners and review dates. Keep a documented recovery route for an identity-provider outage, with restricted emergency access and auditing. Once the pilot behaves as intended, use its access map and test cases to plan the next application rather than buying another product before the policy is clear.