Identity Access Management is hard.
Identity and access management (IAM) covers the identities, authentication methods, permissions, roles, policies, and processes an organization uses to control access. The work includes deciding what access is appropriate and keeping the environment aligned with those decisions as circumstances change.
Consider an employee moving from finance into operations. Their account may stay the same, while their application permissions and privileged access need another look. A manager understands the new responsibilities, but the changes may involve several systems and different administrators. Knowing what the person should have access to is only part of the work. Someone also needs to make sure the systems reflect that decision.
The identity system does not know everything
The identity platform may hold the employee’s account, group memberships, and directory roles. HR records their official position, while their manager knows what the new job involves. Individual applications may maintain their own permissions, and a ticket might contain an earlier request to change them.
A reviewer needs to bring that information together. The directory can show an existing role assignment, but it may not explain why the role was granted or whether the employee still needs it. That answer may depend on a policy, a manager’s knowledge, or an approved exception recorded elsewhere.
IAM technology can enforce access decisions, but determining the appropriate access often requires information from outside the identity platform. When that information is difficult to find, even a routine review can involve several conversations before anyone is ready to decide.
Access is easy to grant and harder to unwind
Permissions can accumulate through ordinary changes in someone’s work. An employee needs access for a project, takes on another responsibility, or joins a group that grants permissions across several applications. Later, they move roles while retaining access from the previous one.
Each grant may have had a legitimate purpose. The difficulty comes when the organization needs to establish whether those purposes still apply. A permission can remain visible long after the reasoning behind it has been forgotten.
Least privilege means limiting access to what is needed for the work. Applying that principle requires an understanding of current responsibilities and a way to revisit earlier decisions. Removing permissions without that context can disrupt legitimate work, while leaving them untouched can preserve access that is no longer appropriate.
Identity is also attractive to attackers
Verizon’s 2025 DBIR credential research reports that compromised credentials were an initial access vector in 22 percent of the breaches reviewed in the 2025 Data Breach Investigations Report. That finding gives organizations a concrete reason to examine how accounts are protected and how their use is evaluated. Verizon
An attacker using valid credentials may produce a successful sign-in rather than an obvious failed attempt. The organization still needs to assess whether the authentication context makes sense and what the account can reach. Protecting the sign-in and reviewing the permissions attached to the account address different parts of that problem.
Authentication does not answer authorization
Authentication checks an identity. Authorization determines what that identity is allowed to do. Multi-factor authentication (MFA) can help protect an account, but it does not establish whether the account has the right permissions.
An employee can authenticate successfully and still retain access from a previous role. Even when an administrator’s sign-in requires MFA, the account may hold privileges that should have expired. A contractor may sign in securely to an application they no longer need for their work.
Access reviews have to consider those permissions separately from the strength of the authentication. The organization needs to understand why the access exists, whether the reason still applies, and who is responsible for approving any change.
Offboarding involves more than one account
When an employee leaves, the organization needs to identify the access associated with that person and determine what should happen to it. This may involve a Microsoft Entra account, privileged roles, group memberships, and applications connected through single sign-on. Other applications may maintain local accounts that also need attention.
Shared resources, API credentials, and service dependencies can complicate the work. The team needs enough context to understand what belongs to the departing employee and what supports a process that must continue. That requires coordination between the people who know the employee’s responsibilities and those who administer the affected systems.
The reason for offboarding also needs to be established. An account with no recent activity in the records being reviewed may deserve investigation, but that observation does not prove its owner has left. A confirmed departure should come from an authoritative source, such as the organization’s HR record.
Once the appropriate changes are authorized and carried out, the team needs to check the relevant systems. The offboarding record should show which access was addressed and what was confirmed afterward, including anything that still requires follow-up.
Access has to match the work
Access decisions need to reflect what people and systems are responsible for doing. A finance employee, developer, administrator, contractor, and service account can have very different requirements. Even people with the same job title may work on different projects or need different applications.
A broad restriction may interfere with legitimate work, while an overly broad grant may leave unnecessary permissions in place. The reviewer needs to understand the specific responsibility and any policy that applies. That context provides a basis for retaining, changing, or removing access.
An exception can be appropriate when its reason is understood and someone remains responsible for reviewing it. Problems become harder to resolve when the permission is still present but nobody can find the original rationale or determine whether it remains relevant.
Keep the review and the change connected
An organization may already use several products for this work. An identity provider handles authentication and directory information. An identity governance and administration (IGA) product may support access reviews and lifecycle processes. Applications and cloud platforms maintain permissions, while tickets track requests and security products surface findings.
Those tools can support the process without containing every piece of information needed for a particular decision. Someone still has to establish which policy applies, who owns the review, and who can authorize a change. A finding may be useful but remain unresolved while those questions are worked out.
We describe the intended workflow as Find → Decide → Fix → Verify. A finding gives the reviewer a condition to investigate. The review establishes whether anything should change, and an appropriate change moves through authorization and execution. A check of the source system then establishes whether the observed result matches what was intended.
The evidence should remain available as the issue moves through those stages. A ticket should carry the review context, and an action should be tied to its authorization. If the resulting state cannot be confirmed, the record should show that the work needs further attention. Operational Zero Trust examines these connections and the evidence that should remain after a change.
Why TPZ is starting with identity and access
Identity and access gives TPZ a defined place to begin investigating this work. 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 intended to test the work around that action as well as the action itself. That includes the information a reviewer needs, how authorization should be recorded, and what evidence should remain after verification and recovery.
Follow one role change
Choose a recent employee transfer and examine how the access review was handled. Find the record of what the new role required, which existing permissions were reviewed, and who approved any changes. Check whether retained access had a documented reason.
Then look at the changes marked complete. Find the evidence showing what the relevant systems returned afterward. Where the record is missing or responsibility is unclear, identify the part of the process that needs attention before the next role change.
