5 Zero Trust Security

Protect resources, not network boundaries

Zero trust is an architectural approach, not a single product. Rather than treating an internal network as inherently safe, it protects individual resources—such as applications, data, and services—and makes access decisions using the request and its context.

Its guiding principles are to verify explicitly, grant least privilege, and assume that a resource or network may be compromised. Continuous verification does not necessarily require a person to re-enter a password constantly; access can instead be reassessed during a session as relevant evidence or risk changes.

Evaluate identity, device, and context

Each request is evaluated using relevant information about identity, device, resource, and circumstances. The decision should account for current organizational rules and the sensitivity of the resource.

Relevant signals can include:

• Identity: the user or service account, authentication strength, role, and requested permissions.

• Device: whether it is known, managed, patched, encrypted, and compliant with security requirements.

• Request context: the resource, time, location, connection, and observed behavior.

• Risk and policy: whether the request meets current organizational rules and the resource’s sensitivity.

For example, an organization might allow a verified employee using a managed, compliant laptop to view a project site, while requiring stronger authentication or denying access from an unmanaged device. Access should be limited to what is needed and for only as long as needed. A change in device health or suspicious activity can trigger a new decision, restrict a session, or end access.

Make and enforce access decisions

Authentication establishes who or what is making a request; authorization determines what it may do. Both apply to human users and non-human identities, including applications and services. Neither should be inferred merely because a request comes from inside the organization’s network.

A common architecture separates three functions:

• The policy engine evaluates evidence and decides whether access should be allowed.

• The policy administrator carries out that decision.

• The policy enforcement point controls the connection to the resource.

These functions may be combined or distributed across services. They rely on trustworthy identity and device information, clearly defined policies, and monitoring that can reveal changing risk.

Limit unnecessary connections

Segmentation divides systems and traffic into smaller, controlled zones. Traditional network segmentation may separate departments or environments, while microsegmentation applies finer-grained rules between individual workloads, applications, or services.

These controls help limit lateral movement: if one system is compromised, an attacker has fewer automatically reachable resources. Segmentation complements decisions based on identity and context; it does not replace them. Network location, such as a subnet, may be a useful signal, but should not be the sole reason to trust a request. For cloud-native applications, policies can use application or service identities as well as network information.

Apply practical implementation patterns

Organizations can combine several patterns to apply zero-trust principles:

• Identity-aware access proxy or ZTNA: routes a user to an authorized application after evaluating identity and, where available, device and request context, rather than granting broad access to an entire internal network.

• Microsegmentation: limits which workloads or services can communicate through narrowly scoped rules.

• Device posture checks: use endpoint-management or security tools to report whether a device meets requirements, allowing policy to respond to its current status.

• Service-to-service identity: authenticates workloads and authorizes their communication individually, including in cloud or microservice environments.

• Centralized policy with distributed enforcement: manages access rules consistently while enforcing them near applications, gateways, endpoints, or workloads.

• Visibility and automation: collects identity, device, network, and application signals to detect changes and update or revoke access when appropriate.

Build capabilities incrementally

Implementation can be incremental. Organizations commonly begin by identifying important resources and users, improving identity and device inventories, defining access policies, and applying controls to a high-value application before expanding.

The CISA maturity model organizes related capabilities around identity, devices, networks, applications and workloads, and data. These areas are supported by visibility and analytics, automation and orchestration, and governance. Together, these capabilities help organizations apply access controls, observe changing conditions, and manage their implementation.