Zero Trust Architecture

Disabling an account only changes the answer given the next time something asks, and an established flow is never asked again. The broker must hold session state and actively terminate matching sessions, which also drops legitimate users the same rule catches.

Zero trust removed network position as evidence, so being inside no longer grants reach. It never claimed to remove credential theft: a real credential on a compliant device is a true input, and every enforcement point downstream will correctly allow it.

Only that something holding the device's credential sent a document containing those claims. The values are the endpoint's own word, and an attacker with code on it can write any of them. Distrusting them costs a narrower grant.

Usually several: an operator opening a shell inside a running workload, node-level access to the host, the platform's own control API on a management network, workload-to-workload calls that never leave, and outbound batch traffic. A front gateway only sees what routing sends it.

A connection-scoped grant authorises the pipe, not the messages inside it: an implant on that laptop can send anything the protocol allows down it, uncredentialed. Deciding per request closes that, at a parse and a lookup per request.

The catch-all at the bottom of the policy decides it, because nothing above it matches. Allow-by-default hands an adversary a path no reviewer ever looks at; deny-by-default breaks integrations nobody can name in advance.

Close to nothing. An attacker takes whichever path is cheapest, so the application's exposure is the most permissive of the two, not the average. You are now funding two policy sets and getting the weaker one's security.

Loopback removes network reach, not local reach: any process or account on that host still opens the port, and the app cannot tell callers apart. It also silently cuts every batch job and integration that connected directly.

The broker can close only the sessions it terminates or proxies, and refuse new ones. Flows that never traverse it — local network, split-tunnel exclusions — die only if the endpoint's tunnel client drops them, and that client runs on the device you just declared untrustworthy.

It asserts a device satisfied a defined checklist - patch level, encryption, management enrolment - when posture was last evaluated. It never asserts that no adversary is operating there, and that answer stands until the claim expires or is re-evaluated.

Only the boot-time measurements it signed, freshly, with a key that cannot leave the hardware. It says nothing about what is running now, so an implant loaded after boot leaves the quote valid and every other field still a claim.

Only the proxy in the workload's own network path. A front gateway never sees a call that does not route to it, and a device agent enforces for a user's endpoint — a compromised workload is not an enrolled device. The proxy's price is one enforcement point per workload to keep consistent.

Per-request decisions need the connector to reconstruct discrete requests, which needs the protocol's framing and semantics. For a database, remote-desktop or vendor binary protocol it cannot, so the grant is all-or-nothing and an implant inherits the whole session.

Watch a full business cycle: quarterly and year-end callers are the undocumented ones. The records cover only subjects that reached that enforcement point, so a path bypassing it, or reuse of an already-enrolled subject, leaves no new entry.

The union of what the two permit, chosen by the attacker. Neither box evaluates the other's decision, so a deny added at one is not a deny for the application. Holding both costs two reviews and two incomplete evidence sets.

Trace the chain: where the decision changed, what learned about it, and what was actually torn down. Long-lived pooled flows with keepalives are never re-decided, so cap session age at the enforcement point and push revocations — and scope aggressive re-decision to high-value applications, not everything.

Make the exemption a server-side property of an identified person and engagement, set out of band, never something the connecting device asserts. Then make the exempt tier deliberately thin, because whoever steals those credentials lands in exactly that tier.

It proves the application accepted connections from a source that is not the enforcement point, so a path exists around the deny. It does not prove malice, does not identify who was behind them, and covers only the paths used during that window — not every path that exists.

Measure the real added latency and where it comes from, then decide per endpoint rather than per service. Concede on high-volume read paths, and state plainly what one open pipe lets a compromised device do on that service.

Ninety more days of allow-by-default on every unlisted subject, plus the risk that whatever an intruder does during the window becomes part of the baseline you promote into permanent exceptions. Log-only defers the denial; it does not de-risk it.

Positive evidence over a full business cycle, not silence. Sampled flow records and a short retention window hide low-volume clients, so run a reversible deny-and-log period first and let the complaints be your inventory before you spend the outage.

Present three residual-risk positions, not three designs: what each leaves an intruder able to do, what it costs, who signs it and when it is reviewed. A two-year rewrite accepts today's exposure for two years.

Say plainly that the attestation buys an audit artefact and an owner of record, not narrower grants. Redirect the same review capacity to the grants that would most help an adversary, and let the long tail expire.

Not in the protocol - it moves to the transport: a per-user, mutually authenticated tunnel terminating on the app host, with the app on loopback behind it. That decides who may connect, never which action they may perform.

Stop treating the far directory's identities as equivalent to yours. Grant them explicitly and narrowly on your side instead of mapping group to group, time-box those grants, require your own step-up for sensitive systems, and measure the other estate's deprovisioning lag.

Almost nothing about content. Flow records prove bytes moved between two endpoints, with counts, timestamps and no payload; the broker's log proves a grant was issued and a pipe existed. Neither shows which records or exports the session carried.

Argue that the headroom buys the ability to actually fire a mass revocation: without it, the reconnect wave takes the broker down and the response becomes one nobody dares run. Then commit only to a measured, scoped number, with offline clients excluded.

Present a signal-by-signal provenance table — attested, inferred, claimed — and state plainly what each survives under a compromised endpoint. Then offer costed choices: fund attesting hardware, shrink what the claimed tier reaches, or keep data off the device.

Treat the bypass as its own control: one named owner, an expiry that defaults to removal, its own strong authentication, and every use reviewed by someone who did not make it. Then make the normal path fast enough at 3am that nobody prefers the bypass.