Security teams already have plenty of tools that can tell them something is wrong.
The expensive part is everything that happens after that.
Someone has to figure out whether the finding actually matters. They may need to pull more context from Microsoft Entra, another system, a ticket, an HR record, or the person who understands why the access exists. Then someone has to decide what should happen, get the right approval, make the change, check whether it worked, and keep enough evidence to explain the decision later.
That work takes time.
It creates handoffs.
It can leave a risky condition sitting unresolved longer than anyone wants.
And when access is changed incorrectly, or a legitimate user cannot get what they need, the cost can show up somewhere else: employee downtime, support work, delayed operations, and more time spent undoing the change.
That is the problem we are trying to solve with Trust Player Zero.
Our Beta is helping us understand what has to exist between finding a risk and knowing it was handled correctly, without creating unnecessary downtime along the way.
The value is not another finding
TPZ starts with identity and access in Microsoft Entra.
During Beta, we are testing findings around conditions such as dormant enabled users, privileged accounts, dormant privileged users, MFA registration gaps, stale guest accounts, and access that needs review.
Those findings are useful.
But simply adding another alert to a security team's queue does not create enough value.
The opportunity is to reduce the manual work that begins after the alert appears.
A security team should be able to move from:
Something looks wrong.
to:
We understand what is happening, we know what should happen next, the right person approved it, the action was carried out, and we can prove the outcome.
That is the workflow TPZ is being built to support.
The faster a team can get to that answer, the less time the issue sits unresolved and the less time people spend chasing context across systems.
First, the finding needs context
Take a simple example.
TPZ may observe that an enabled account has not shown sign-in activity for 90 days.
That is useful information.
It does not automatically mean the account should be disabled.
Maybe the employee is on leave.
Maybe the account exists for a specific business purpose.
Maybe the available sign-in data is incomplete.
Maybe another system contains information that changes the decision entirely.
This is where security work often becomes manual.
Someone has to investigate.
Someone has to figure out what information is missing.
Someone has to decide whether the evidence is current enough to trust.
Someone may have to move between multiple systems before they are comfortable making a decision.
That investigation has a cost.
While the team is figuring it out, a risky condition may remain open. On the other side, acting too quickly can create its own operational problem if the wrong account is disabled or access is removed from someone who still needs it.
TPZ Beta is testing how much of that context can be brought into the workflow around the finding.
We want the product to help answer questions like:
Who is this identity?
What access does it have?
What evidence created the finding?
How recent is that evidence?
Is the data complete?
Is another source telling us something different?
What would actually change if we act?
What information still requires customer judgment?
That context is what makes a finding useful enough to act on.
Better context should mean less investigation time and less downtime
This is where the business value becomes very practical.
Security teams should not have to spend their day acting as the integration layer between every tool involved in a security decision.
Today, resolving one identity issue can mean moving among dashboards, Microsoft Entra, tickets, email, spreadsheets, approval records, and evidence folders.
Each handoff adds time.
Each handoff creates another place where context can get lost.
And slow or incorrect access decisions can affect the business in two directions.
If action takes too long, an unnecessary or risky access condition can remain in place longer.
If action happens without enough context, the wrong person can lose access and work can stop while the problem is corrected.
TPZ is being designed to reduce that gap.
The goal is to help the person responsible for the decision get to an informed answer faster, with the relevant evidence and context attached to the issue.
That can mean less time spent investigating, less waiting between teams, less unnecessary disruption, and less time spent repairing the consequences of a bad decision.
Not because every decision should be automated.
Because the human making the decision should not have to rebuild the entire story from scratch.
Then someone has to decide what actually happens
Context does not replace human judgment.
In Beta, the customer Admin remains responsible for the decision.
TPZ separates what the system can observe from what the customer decides.
That distinction matters.
For every finding, we want to preserve:
What we observed
The facts supported by the available data.
What those facts mean
A clear explanation of the condition.
What might need to happen next
A supported next step for review.
What the customer decides
The customer's judgment based on technical evidence and business context.
This avoids one of the easiest mistakes for security software to make: turning an observation into a conclusion that the evidence does not actually support.
If TPZ does not have enough information, the answer should be that more information is needed.
If the data is stale, the product should say so.
If two sources conflict, that conflict should remain visible.
If the answer is unknown, TPZ should not manufacture certainty.
That is important for security.
It is also important for uptime.
A safer decision is not simply one that reduces risk. It is one that avoids creating unnecessary disruption while doing it.
Approval alone is still not enough
There is another problem we are testing.
The environment can change after a decision is made.
An administrator may review an identity and approve an action at 10:00 a.m.
Something about that identity may change before the action is executed.
Now the question is not simply:
Was this approved?
It is:
Is this still the same situation that was approved?
The Beta workflow is being designed to check the relevant current state before supported actions move forward.
If something material changed, the workflow should be able to stop or return the issue for another decision instead of blindly relying on an old approval.
For the customer, that means the approval is connected to the actual conditions around the action, rather than existing as a detached checkbox somewhere in a ticket.
It also reduces the chance of making a technically valid change that no longer makes sense by the time it happens.
Then TPZ can help carry the decision through
Once the evidence, customer context, current state, and authorization line up, the workflow can move toward action.
This is the part of Beta where TPZ begins taking on more responsibility.
For supported Microsoft Entra actions, the target is a workflow that ties the action to the specific customer, identity, current state, administrator, supporting evidence, expected result, and authorization.
That means a security team should be able to answer:
Who approved this?
What did they approve?
Which identity did it apply to?
What was true when they approved it?
What action was actually sent?
What was supposed to happen afterward?
Instead of that information being spread across several systems, TPZ is being designed to preserve it as one connected workflow.
The business value is straightforward.
Fewer handoffs.
Less waiting.
Less manual coordination.
Less time spent reconstructing why something happened.
And, when the workflow works the way we intend, less unnecessary downtime caused by slow or poorly informed access decisions.
And then we need to prove what actually happened
This may be the most important part.
A successful API response does not necessarily mean the security problem was resolved.
If TPZ sends an approved action to Microsoft Entra, we want to independently read the relevant state back when Microsoft exposes a state we can verify.
If the intention was to disable an account, the real question is whether Entra now reports that account as disabled.
That allows the workflow to distinguish between:
We sent the request.
and:
We verified the resulting state.
Those are very different levels of confidence.
The Beta is also testing how TPZ should handle cases where the result does not match what was expected or where the resulting state cannot be confirmed.
The goal is to preserve an evidence chain that connects:
Finding → Context → Decision → Authorization → Action → Result → Verification
That record can be useful long after the original issue is resolved.
For security leadership.
For auditors.
For customer questions.
For the next person who needs to understand why a change was made.
And for the team trying to avoid repeating the same investigation the next time something similar happens.
This is the business value we are trying to prove
The Beta is not simply testing whether TPZ can identify another security issue.
We are testing whether TPZ can reduce the work between seeing a risk and knowing it was handled.
That means helping teams:
Spend less time gathering context manually.
Move from findings to informed decisions with fewer handoffs.
Reduce the time risky conditions sit unresolved.
Avoid unnecessary employee or operational downtime caused by poorly informed access changes.
Keep customer judgment and authorization attached to the action.
Avoid acting on stale or incomplete information.
Verify that the intended change actually happened.
Preserve the evidence without rebuilding the story later.
That is the part of security operations we think has room to become dramatically easier.
Security teams already have more findings than they know what to do with.
We do not need to make those findings louder.
We need to help teams understand them faster, act with the right context, reduce the time and disruption between finding and resolution, and prove what happened afterward.
That is what we are working to prove in Beta.
