A contractor finishes a project. Their office pass and VPN access are disabled, but yesterday's session in the contracts application still works. The offboarding checklist is complete; access to the actual documents is not.
This is a useful starting point for Zero Trust. The old controls are not worthless. They simply do not answer the application's question: is this person still allowed to read this particular contract? That decision needs its own basis, regardless of the network carrying the request.
What happens after sign-in?
Authentication establishes identity, not permission to use everything in the system. Zero Trust focuses on protected resources, the person or service requesting them, and the conditions for access. A corporate network address or company-owned laptop does not, by itself, establish implicit trust. This is the distinction made in NIST SP 800-207.
For contracts, an employee might read documents belonging to an active project from an acceptable device. Bulk exports or contractual changes require separate authority. If their account is compromised, narrower permissions reduce the available damage. They do not make every action legitimately allowed to that account harmless.
Zero Trust therefore does not replace backups, endpoint protection or vulnerability management. Nor must a company declare its VPN useless. A protected communication channel can still matter; permission to read a document is a different control.
Where is the decision enforced?
An access policy might say that current project members may read that project's contracts. Enforcing it requires information about the user, the project and the requested action, followed by a component that permits or rejects the request. Enforcement can live in an application, an access intermediary or several coordinated places.
The weakness is often a route around the check. The main interface denies access, but an old direct file link still works. Or an API serving the same document checks only whether someone has signed in. Adding a common login page does not close those gaps.
Follow one document through preview, download, search and export. Permissions should mean the same thing across those routes. Disabling an account also cannot recall a copy already downloaded; controlling further disclosure needs its own treatment.
Reassessment does not mean endless password prompts
People need not sign in before reading every row of a report. Applications can evaluate access automatically using the active session and available information. Additional confirmation belongs where risk or consequences justify it, not wherever another prompt can be inserted.
But information ages. A contractor leaves the project, a device becomes unsafe, or a temporary assignment expires. The company must decide when that change must take effect in the application. Short token lifetimes reduce some exposure, but do not explain what happens to established sessions or separately granted local permissions.
Some platforms send events that participating applications use to reassess access. Continuous Access Evaluation in Microsoft Entra, for example, depends on application support and event propagation. It is a mechanism to examine, not a promise that installing one product instantly disconnects every system.
The contractor's automation needs its own review
Removing a person's access is insufficient if their overnight script continues through a shared technical account. Human assignments and automation permissions need separate ownership: who maintains the integration, what may it do, and when will it no longer be required?
An import process may need to read an agreed directory and create a particular kind of record. It generally does not need authority to change users. Least privilege is more useful here than a universal account that makes everything convenient to deploy.
The credential establishing the service's identity has a lifecycle too. Revoking it and issuing replacement authority are distinct operations. Changing an employee's password does not prove that every integration they created has stopped working.
When the access check itself is unavailable
Authorisation introduces dependencies of its own. If the system cannot obtain an up-to-date project assignment, the team must know which operations stop and whether previously verified information may be used within defined limits. A failed check must not silently become unrestricted access.
For a new sensitive permission, the safe outcome is denial until the necessary conditions are established. Continuing narrowly defined work may have a separately approved policy. Its scope, duration and records should be tested before an outage rather than invented during one.
Administrators also need controlled emergency access so that a broken policy does not prevent its own repair. That route should not depend on the single failed login path. Its use must be restricted, monitored and reviewed. Microsoft's emergency-account guidance describes this operational concern; it is not a justification for a shared daily-use master password.
Start by ending one project properly
Choose a process involving external participants before attempting a company-wide replacement. Record who approves assignments, which documents are available and the acceptable delay in removing access. For legacy software, first establish where enforcement is possible instead of promising identical integration everywhere.
End a test assignment while keeping a browser session open and an API request ready. Check a new login, the existing session and document download. Then let a current project member continue ordinary work: removing one person's access should not disable the project.
The useful result is a known boundary: which routes close, how quickly, and which exceptions remain. Give those exceptions owners and review dates. That is more informative than the number of applications connected to an identity platform, which says little about what happens when someone's work actually ends.