Zero Trust: start with decisions

When I discuss Zero Trust, I want to know which access decisions we are making and what evidence supports them. The aim is to reduce implicit trust and protect resources according to the activities the business needs.

Start with a decision that matters

When someone proposes a Zero Trust project, I want to know which access decision we will improve first. Starting with a technology list is easy; explaining which activity someone may perform and which conditions prevent another takes more work. That explanation lets us discuss the design with the business.

I would choose a resource with an identifiable owner and activities we can test. Before making changes, I would document current access, existing permissions and alternative routes. This baseline stops us evaluating only the new product while leaving the previous route open. It also lets us agree on the intended result and who should validate it. The scope should be specific enough for teams to explain what has actually changed.

The architecture question

Who or what requests access, to which resource, for which action and with what evidence? Identity, device, resource sensitivity and context belong in the conversation.

A practical first step

Choose a critical service and map its access journey. Identify where authentication occurs, how authorization works, which privileges are granted and when they are reviewed or revoked.

Signals need a defined response

Knowing a device’s state only helps if we know what to do with that information. Do we block access when a condition is missing? Allow only a limited activity? Who helps the user if the information is wrong? Those decisions belong in the design.

I would also review the quality and freshness of the signals. A check performed hours earlier may not represent the current session. If a source stops responding, we need an agreed behavior based on the resource’s impact. I would not set one response for the whole organization: continuity requirements and the consequences of allowing access differ between services. We should document who owns those choices and how users recover from a legitimate denial.

Authentication does not authorize every action

In the financial example, confirming identity is only one part. We may need to distinguish reading a record, changing a payment account and approving the final change. Each action can require different permissions and conditions, even inside the same application.

If the application cannot support that separation, we must acknowledge it. A new access layer does not guarantee that internal permissions are appropriate. We need to review how entry policies combine with application roles. I would also check that APIs, technical accounts and direct access routes are included. A protected interface can coexist with another path that permits the same operation without that control. Testing only the user interface would leave an important assumption unverified.

Example: access to a financial application

Consider an application supporting routine queries and changes to payment account details. Both actions belong to the same service but have different impacts. A design proposal may allow queries under normal conditions and require an additional check before changing payment details. The decision should distinguish the person, the action and the context; checking only that the user signed in leaves that difference unrepresented.

Review questions

What happens if an authorized session changes context? Can high-impact actions be constrained? Is there an operational alternative when an access dependency fails?

Test context changes and failures

I would not stop at a test where an authorized user successfully connects. I want evidence that an identity without permission cannot perform the action, that a relevant context change triggers the expected response, and that access removal works in practice.

Tests should include sessions already in progress. Removing an assignment and ending a session can behave differently. We need to know what happens to tokens and running operations. I would also test dependency failures, lost connectivity and service recovery. Recording what we cannot control defines a concrete limitation instead of assuming the product solves everything. Each result should identify the conditions tested, the expected behavior and the person responsible for closing any gap.

Who changes policy and how it is validated

Access policy also needs a change procedure. If we alter a condition to resolve an incident, I want to know which users and resources are affected, who authorizes it and how we check that scope has not expanded unintentionally. A broad rule may fix one case while allowing others that were never intended.

Before deployment, I would test representative scenarios for the affected activities. Afterwards, I would review logs and the behavior of users who must keep working. I would also define how to return to the previous configuration if results differ from expectations. The operating team needs this information and an explanation of dependencies that may change the rule’s effect.

During periodic reviews, I would select policies and ask for examples: what they allow, what they prevent and which need justifies them. If nobody can answer, investigate before retaining them out of habit. The same reasoning applies to exclusions. An exception introduced during an incident can remain active long after the original issue is resolved. Reviewing that lifecycle helps prevent the model from deteriorating with every change. Architecture should still describe what happens in the service after months of operation, with policy changes linked to their owners, test results and continuing business purpose.

What to measure and what to avoid

Recording decisions and the signals used helps reveal exceptions that become routine access. Separate coverage from effectiveness: deploying a control does not demonstrate that it prevents a sensitive action. Zero Trust should not be confused with repeatedly requesting authentication; each check needs a purpose and a defined response.

Roll out by service and review exceptions

I would progress by service or user group, with a scope we can operate. This lets us resolve incidents and adjust policies before extending the rollout. But each phase needs completion criteria: what was validated, which previous routes are removed and which exceptions remain unresolved.

An exception needs a purpose, an owner and a review. If the same need keeps returning, we may need to add a use case to the design. To assess progress, I would look at coverage, access outside the model, revocation times and authorization test results. User onboarding figures help, but I need to know whether decisions work as intended. That evidence supports the architecture and helps us revise it when the business changes.

Further reading

Official sources for checking and exploring these concepts. This article presents a practical approach; it does not reproduce the references’ full requirements.

• NIST SP 800-207

Examples are illustrative. Implementation decisions should be adapted to each organization’s requirements and dependencies.