What zero trust means in practice

For access to company accounts and services, zero trust checks who or what is requesting access, which resource it needs, and whether the request meets the organization’s rules. An office network or virtual private network (VPN) connection does not grant broad access.

Organizations limit permissions, check information about users and devices, and control access to each resource. Zero trust is an approach to access decisions, not a single product or a guarantee that attacks will stop.

How Zero Trust Decides Access

Consider an employee using a personal laptop to open a company service. The organization can check the employee’s identity and permissions, the laptop’s security condition, and the sensitivity of the resource. It then grants the access allowed by its rules and monitors activity according to those rules.

Employees need not sign in again for every action; access to each resource still depends on the organization’s rules after login or a connection to the company network. The organization can limit or revoke access when those conditions change. The exact checks depend on the resource, the organization’s policies, and the available information.

NIST describes three roles that help explain how this works. A policy engine evaluates whether to allow, deny, or revoke access. A policy administrator puts that decision into effect, such as by setting up or ending a session. A policy enforcement point controls the connection to the resource. Products may combine these roles or divide them among different services.

Limit Permissions and Exposure

A zero-trust approach starts by identifying the people and non-human accounts that need access. A service account, for example, is an account used by software to connect to another service. Both employee accounts and service accounts need permissions that match their actual tasks.

Organizations also need to know which devices, services, and data they have. That information helps them decide what is requesting access and which resources or data the request could expose. A complete inventory may take time, so NIST advises organizations to account for newly discovered assets as they find them.

Permissions should cover only the resources and actions a task requires. An employee who needs to view one set of records should not automatically be able to change other records or reach unrelated services. The same principle applies to devices and software accounts. It limits what an intruder can reach if an account or device is compromised.

Firewalls can restrict connections between systems. Network segmentation divides a network into smaller sections and can also restrict those connections. Zero trust extends access decisions to individual resources, including cloud services, applications, and data. CISA’s Zero Trust Maturity Model groups this work into five areas: identity, devices, networks, applications and workloads, and data. It also highlights visibility, automation, and governance as capabilities that support those areas.

Use Security Signals Carefully

Access decisions can draw on information such as a user’s identity, a device’s condition, activity logs, and threat intelligence. Monitoring those signals helps an organization spot activity that needs a closer look and update access when policy conditions are no longer met.

More monitoring also creates privacy responsibilities. Inspecting network traffic and keeping detailed logs can expose personal information, including sensitive attributes. NIST advises organizations to consider these risks when they plan monitoring, rather than treating data collection as harmless by default.

Begin With One Workflow

Replacing every security tool at once is rarely a practical starting point. NIST recommends a phased migration: identify important business processes and resources, understand how data moves, and choose a manageable place to begin. Older network controls and newer zero-trust measures may operate side by side during the transition.

A practical rollout can follow this sequence:

1. Map one important workflow, including the people, service accounts, devices, resources, and data it uses.
2. Decide which identities need access, what they may do, and what conditions should apply.
3. Put an enforcement point in the path to the resource so the rules actually control access.
4. Before expanding the approach, review access logs; assess user impact and operational problems.

A lower-risk workflow can be a useful first choice because policy errors are less likely to interrupt critical operations. Before expanding, check whether legitimate users are being blocked, whether permissions remain broader than necessary, and whether the tools exchange the information needed to enforce policy.

NIST’s June 2025 implementation guide presents 19 example implementations developed with 24 collaborators. The examples show different ways to combine commercially available technologies, including identity controls, network segmentation, and secure access services. They are demonstrations of possible designs, not proof that one configuration suits every organization or produces the same results in live operations.

Weigh the Costs and Limits

Restricting access to specific resources can reduce how far a compromised account or device reaches. Better visibility into access also gives security staff more information to investigate unusual activity. These are expected benefits, not guaranteed outcomes. There is no established general percentage for how much zero trust reduces breaches or attack costs.

Implementation takes planning and ongoing work. Organizations need reliable information about their accounts, devices, services, and data. Tools that they already own may not integrate smoothly, and older systems can complicate the transition. Staff also need time to set policies, maintain them, and respond when access rules disrupt legitimate work.

Poorly tuned rules create a different risk: they can block normal tasks or frustrate users without improving protection enough to justify the disruption. Organizations should test policies against real workflows and adjust them before applying them more broadly. They should also decide what information they need to collect and how long they need to keep it.

CISA describes stages organizations can use to track their progress, but there is no single standard point at which everyone agrees an organization has a fully functional zero-trust architecture. Progress depends on the organization’s systems, risks, and goals. A federal policy that set objectives for U.S. agencies does not create the same requirements for every private organization.