Zero Trust Without The Vendor Fog

Putting an application behind a VPN doesn't answer who may read the records inside it. Adding SSO improves the login, but an old API token or a directly reachable origin can leave another way in.

That's why I prefer to start a Zero Trust discussion with one application and its access paths. It's easier to discover what needs to change when you can name the resource, the caller, and the operation.

NIST SP 800-207, published in August 2020, makes resources the focus and rejects implicit trust based solely on network location or asset ownership. The practical consequence is that “already on the internal network” cannot be the whole authorization decision.

Follow three kinds of access

Take an internal reporting application. Employees open dashboards, a contractor downloads a subset of reports, and a scheduled job exports data overnight. All three reach the same service, but they need different authority.

The employee may use SSO and a managed laptop. The contractor's grant may be limited to one project and an end date. The job needs a workload identity that can perform its export without inheriting a human administrator's permissions.

List the paths each uses. Include the browser, API, origin server, database access, support tools, and scheduled workers. If a proxy protects the browser path while the original endpoint remains reachable, the application still has two access designs to review.

I'd draw those routes before choosing another product. It makes the missing controls visible and gives the migration a bounded place to begin.

Decide at the resource

Authentication establishes who or what is making a request. The application then needs to decide whether that identity can perform this operation on this resource.

For the contractor, checking membership in “reporting users” may be too broad. The access decision may need the project, report sensitivity, grant expiry, and requested operation. Viewing one report and exporting every customer's records shouldn't become equivalent merely because both use the same application.

Keep those decisions close enough to the resource that the application can enforce them. A stronger login at the edge helps, but it cannot infer every business relationship behind an object ID.

Logs should preserve the subject, action, resource, and decision. That lets you explain a disputed access request without relying on a generic “user authenticated” event recorded several services earlier.

Device and network controls still have work to do

Device posture can contribute to an access decision, provided the signal is current enough to use. A laptop that reported encryption and endpoint protection three weeks ago may no longer have the same state. Define how old a signal can become and what access remains available when it expires.

Reauthentication should have a reason the user can understand. Repeated unexplained prompts teach people to approve them automatically. Sensitive operations can require a fresh check while ordinary work continues under an appropriately bounded session.

Segmentation limits what a compromised machine can reach. For the reporting service, ordinary workstations might need the application endpoint while only a management network can reach administration interfaces. The export worker may need database access that the web frontend doesn't.

Test the rules from the relevant source networks. An entry in a firewall configuration is an intended policy; a connection attempt tells you whether another route or broad exception defeats it.

Revocation is where the details show up

Disable the contractor's identity and try the application again. Then repeat the test with an existing browser session and an API token issued before the account was disabled.

Those cases can behave differently. A new login may fail while an application session or cached authorization remains usable. The team needs to know how long each can survive and whether sensitive access can be cut off sooner.

Scheduled work deserves the same attention. If the overnight export uses a former employee's credential, the departure process may either break the job or leave an account active indefinitely. Give the job an owned, scoped workload identity and a rotation procedure that doesn't depend on keeping someone else's account alive.

A revocation test should end at the data. Measure when access actually stops, and keep a record of paths that need manual action. That is more useful than counting disabled directory objects.

Migrate one application completely

For the reporting application, I'd first close direct access that bypasses the intended controls and deal with privileged credentials. Then I'd test the employee, contractor, and scheduled-job paths under normal use, expiry, and dependency failure.

If the policy service is unavailable, define which requests can use bounded cached decisions and which must wait. A request for a sensitive export may need different handling from viewing a low-risk dashboard. Give operators a visible indication when enforcement is degraded so temporary behavior doesn't become a forgotten default.

Keep the people using the application involved in those tests. A control that prevents their legitimate task will produce support pressure and workarounds. Fix the workflow while keeping the resource's permission rule intact.

Once that application has an understood grant and revocation path, use it as the starting pattern for the next one. The useful progress measure is how much sensitive access now follows a rule you can explain and test, including the paths that never open a login page.