Zero trust in practice: protect access to one application first

Being inside the network is not an access decision

Cloud applications, remote work and external collaborators make it difficult to treat a network boundary as the whole security model. The important question is whether a particular identity should access a particular resource under the present conditions.

NIST SP 800-207 describes zero-trust architecture as a resource-focused approach that does not grant implicit trust based only on network location or ownership. Google’s BeyondCorp is a well-known implementation that moves access decisions toward users and devices. Neither idea means that one purchased product makes an organization secure.

1. Choose one resource and map its callers

Our recommendation is to start with a clearly owned application rather than announce an estate-wide replacement program. Identify the employees, contractors, administrators and automated services that call it. Include background integrations that may never appear on an interactive login screen.

Record what each caller needs to do. Viewing a report, changing customer data and administering the application should not silently inherit the same access. Check the actual data paths, including exports and direct backend connections, before deciding where policy can be enforced.

2. Make the policy understandable

BeyondCorp’s published model uses user- and device-based authentication and authorization to support access from untrusted networks. That is a concrete example of using context beyond whether a request originated on a corporate network.

For your pilot, express the intended access in plain language before turning it into rules. Identify the permitted group, the resource, the required authentication and the relevant device conditions. Establish who approves exceptions and when they expire.

Test denied cases as carefully as allowed ones. Ask what happens to an unmanaged device, a disabled account or an integration using an expired credential. Avoid weakening an entire rule because a single unexplained exception interrupts work.

3. Keep application and service authorization in view

An access gateway can protect an entry point, but the application still needs to enforce what an authenticated user may do. Verify that alternate hostnames, direct network paths and internal APIs cannot bypass the intended checks.

Automated workloads need their own identities and authorization lifecycle. Our suggested review asks who provisions those identities, where credentials are held and how access is revoked. Treat service-to-service access as part of the design rather than a permanent bypass for background jobs.

Network controls remain useful alongside identity controls. The change is to stop treating network position alone as sufficient proof that every downstream action should be trusted.

4. Plan for policy and identity failures

A stricter policy can become an availability problem if nobody can diagnose a legitimate denial. Add an understandable support path, useful audit evidence and a controlled recovery process. Log the decision context needed for troubleshooting without collecting unnecessary sensitive content.

• Can the owner explain why a request was allowed or denied?
• Are non-human callers represented in the policy?
• Are bypass paths and temporary exceptions tracked?
• Can the team recover access without leaving a permanent back door?

Before expanding, rehearse loss of access to an administrative account or a required identity dependency. Define a tightly controlled emergency procedure, who can use it and how its use will be reviewed. These are operational recommendations, not a claim that the pilot meets a particular compliance standard.

Expand after the first resource is operable

Review failed logins, exceptions, support effort and the application’s authorization behavior. Resolve unexplained access paths before copying the design to more services.

Use NIST for the architectural concepts and BeyondCorp for implementation history. Choose products only after your resource, identity and operating requirements are clear.