Operational Zero Trust
An access review can involve an identity platform, a manager, an administrator, and a ticketing system. The organization needs to decide whether the access is appropriate, authorize any change, and check what happened afterward. Following that work gives us a practical way to examine how Zero Trust operates beyond the configuration of an individual control.
I use Operational Zero Trust here to describe the process around those identity and access decisions. My focus is on access reviews and administrative changes, including the evidence people need, the authority to act, and the record that remains afterward. It is one part of implementing Zero Trust, rather than a definition of the entire architecture.
NIST SP 800-207 describes Zero Trust architecture in terms of infrastructure and workflows. It rejects implicit trust based solely on network location or asset ownership. The CISA Zero Trust Maturity Model also includes governance, automation and orchestration, and visibility and analytics across its pillars. The operating process is already part of that guidance. An access review gives us a specific place to look at how it works in practice. NIST Computer Security Resource Center
Follow the access decision
Consider a reviewer looking at someone’s privileged access. The directory may show the role assignment, while a manager understands the person’s responsibilities. An application may maintain separate permissions, and an internal policy may describe what access is expected. Before deciding whether anything should change, the reviewer needs to understand how that information fits together.
The technical condition alone may leave important questions unanswered. An account with no recent observed activity may deserve review, but inactivity does not establish that the account should be disabled. A privileged role may have a legitimate business purpose. The reviewer needs enough context to distinguish an issue requiring action from access that is appropriate or covered by an approved exception.
When that context is scattered, people have to gather it themselves. They compare screens, look through tickets, and ask colleagues what they know. After a decision, someone still has to carry it to the person authorized to make the change. The tools may be functioning as intended while the work between them depends on manual follow-up.
Keep the steps connected
We describe the workflow as Find → Decide → Fix → Verify. A finding brings a condition to someone’s attention, supported by evidence from the environment. The review establishes whether a response is needed. When a change is appropriate, it moves through authorization and execution before the resulting state is checked.
Each stage needs enough information from the previous one to proceed. The reviewer should be able to see why the condition was surfaced. The person carrying out a change should know exactly what was approved, and the verification should check the intended result. A decision to retain access or defer action also needs a recorded reason, rather than disappearing because no change was made.
Keeping those records together lets the next person continue without reconstructing the earlier work. It also makes gaps easier to identify. A finding may have been reviewed but still need authorization, or a change may have been attempted without its result being confirmed.
Check the source system after a change
A closed ticket, a submitted request, or a successful API response can tell us something about the work that was attempted. To establish whether the intended state was reached, the team needs to check the system where the change was supposed to occur.
If the intention was to disable an account, read its state back and check whether it is disabled. If a role assignment was supposed to be removed, check that assignment in the source system. Record when the check took place and whether the observed result matched the decision.
A mismatch needs follow-up. So does a check that fails or cannot establish the result. Verification should preserve that uncertainty rather than treating an unavailable answer as success. It confirms a specific observed state at a particular time; it cannot guarantee that another process will never change that state afterward.
Keep the evidence with the work
Imagine an access review is completed and an auditor asks about it six months later. The decision may be in a ticket, the approval in email, and the result in a separate log. Someone now has to connect those records before explaining why the access was changed and whether the change occurred.
The original workflow should preserve the information needed to answer that question. Keep the finding with its supporting evidence and the reviewer’s reasoning. Record who authorized the action, what was attempted, and what the source system showed afterward. Any uncertainty or further work should remain visible in the same history.
That record gives a later reviewer something to examine without relying on the original participants’ memories. It can also help the team investigate a returning condition. They have a basis for checking whether the earlier change took effect or whether something changed again afterward.
Define what automation is allowed to do
There are opportunities to reduce the repeated work around a review. Software may help gather information, summarize evidence, or route a finding to the responsible person. Giving software permission to change an environment requires additional decisions about its authority.
Before enabling an action, establish who can authorize it, which accounts or systems it can affect, and what conditions must be satisfied. Decide what evidence should be retained and how the result will be checked. The organization also needs to understand how an incorrect or unwanted change would be handled, including what recovery is possible and who can approve it.
Those boundaries belong in the workflow before the action occurs. They give people a way to oversee the work and investigate its result as more tasks are handled by software.
Where TPZ is starting
TPZ is beginning with identity and access. When configured for live access, TPZ can read supported Microsoft Entra and Azure identity and access information, subject to permissions and current coverage limits. This starting point is read-only and does not include changing a customer’s Entra environment.
The Design Partner Beta is designed to begin with an evidence-backed Microsoft Entra identity and access audit. It is intended to progress toward a customer-authorized account-disable action, followed by read-back verification and retained evidence. The target also includes an authorized re-enable process with verification of the restored state. These are Beta targets, not capabilities the current product already performs.
The program is designed to explore what information helps a reviewer decide and how authorization should connect to an action. It is also intended to test the evidence needed to verify the result and support recovery. TPZ’s longer-term direction is a cross-system security control plane, but that remains future direction. The immediate work is to test this defined identity workflow before making broader claims.
Five questions to ask about your own environment
Choose one recent identity or access review and follow its record from the initial finding through the final check. This is a way to examine that workflow, not a complete assessment of a Zero Trust program.
Can we understand why the condition deserved attention and find the evidence used to review it?
Is it clear who owned the decision and who had authority to approve a change?
When a change was made, did someone check the source system and record the result?
Does the reasoning behind the decision remain connected to the action?
Could someone explain the work six months later without rebuilding its history from messages, spreadsheets, and memory?
Where an answer is unclear, identify the missing information or responsibility. Choose one part of the process to improve, then examine the next review to see whether the change helped. That gives the team a specific way to improve how an access decision is handled.
