An attacker's tunnel outlives the account being disabled: what must an access broker do to end it, and who else gets dropped?
answer
- revocation is a decision, not a packet
- nothing re-asks an established flow
- keepalives stop it ageing out
- the broker must hold session state to kill it
- the same predicate drops innocents
basics
~20 sDisabling 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.
solid answer
~50 sRevocation is a control-plane event; the attacker is in the data plane. When the broker permitted the connection it made one decision, at setup — nothing inside an established TCP or QUIC flow ever consults the policy engine again, and keepalives keep the flow from ageing out. So disabling the account stops *new* connections and nothing else. Ending the live flow needs three things to be true: the enforcement point holds per-session state so it can tell which live sessions the revocation matches, the changed decision reaches that enforcement point by push or poll, and it can actually terminate — close the proxied session or have the endpoint's tunnel client drop the tunnel. The price is that a revocation is a predicate, and a predicate wide enough to catch the attacker also drops every legitimate session it matches: stalled uploads, dropped calls, and a help-desk ticket each.
go deeper
Be ready to state plainly that disabling an account blocks new connections and does not close open ones, and to name the one thing that must exist for a teardown to be possible: session state at the enforcement point.
Explain why an established TCP or QUIC flow is never re-authorised, how keepalives keep its state entry alive, and the three steps between a revocation being issued and a flow actually dying.
Show that you plan the collateral before you run the predicate: how many live sessions it matches, who absorbs the drop, and what re-admission looks like in the ten minutes afterwards.
Own the tension that a revocation wide enough to catch an adversary is disruptive enough that people hesitate to run it, and that a control nobody dares fire is not a control.
## What "revoke" actually does In a zero-trust design the decision and the enforcement are separate things — NIST SP 800-207 calls them the policy decision point and the policy enforcement point. A decision happens at a moment: a request arrives, the enforcement point asks, the answer is yes, and traffic starts flowing. Disabling the account, failing the device's posture, or deleting the grant changes the answer that will be given **the next time somebody asks**. It does not reach backwards into a flow that was already permitted. That is the whole misconception this question exists to break. Candidates say "we disabled the account" as though it were a containment action. It is an admission-control action. ## Why the flow persists - **Nothing re-decides an established connection.** Neither TCP nor QUIC carries an authorisation credential per segment, and neither asks anyone whether the flow may continue. The authorisation lived in the handshake that opened it. - **State entries are long-lived and keepalives refresh them.** A connection-tracking entry for an established TCP flow sits on a timeout measured in days, not minutes, and application keepalives reset the idle timer long before it expires. - **Applications hold connections open deliberately.** A database or message-bus client keeps a pooled connection open for days precisely so it does not pay setup cost. That pooled connection was authorised once, at process start. So an adversary who established a session five minutes before you revoked keeps a working channel for as long as they keep the bytes moving — unless something tears it down on purpose. ## What ending it requires Three conditions, all of them: 1. **State to match against.** The enforcement point must know which live sessions belong to that principal or device. A filter that only sees packets, with no session identity, has nothing to match a revocation predicate against. 2. **A signal that arrives.** The changed decision has to reach the enforcement point — pushed as an event, or discovered on the next poll. The poll interval is your floor on how fast anything can happen. 3. **The ability to terminate.** Two places can execute a teardown: the broker's own session table, for sessions it terminates or proxies; and the tunnel client on the endpoint, which can drop the tunnel outright. Note the awkwardness of the second one — it runs on the device you may have just declared untrustworthy. ## Who else gets dropped A revocation is a predicate: *this account*, *this device*, *every device below this OS build*, *every session older than N*. A narrow predicate is safe and often misses; a wide predicate is effective and expensive. Flip a posture rule across a large remote workforce and you have not performed a surgical action — you have disconnected thousands of people who were doing nothing wrong, each losing whatever was in flight, and a fair share of them calling the help desk in the same ten minutes. That collateral is not a footnote. It is the reason revocation predicates get quietly narrowed over time until they no longer reliably cover an adversary, and it is why the honest answer to this question names both halves: what the teardown reaches, and who pays for it. ## What a good answer sounds like "Disabling the account stops new decisions; it doesn't kill open flows, because nothing re-evaluates an established connection and keepalives stop it timing out. To kill them the broker has to hold session state and terminate the matching sessions, and the endpoint's tunnel client has to drop the tunnel — with a lag of seconds to minutes depending on how the signal reaches a client that may be asleep on hotel wifi. And the blast radius is everyone the predicate matches, so I'd scope it and warn the service desk before I ran it."
- If the account is disabled, why can the adversary's existing flow still reach the application at all?Because the application is trusting the connection, not re-checking the principal. Authorisation was consumed at setup: the broker admitted the flow, and from then on the application sees an ordinary established connection. Unless the app itself re-validates a bearer credential on every request, or the enforcement point terminates the session, nothing between the adversary and the data asks a second time.
- Where does the lag between revoking and the flow actually dying come from?Three places. The decision has to propagate from wherever it was made to the enforcement point — instant if pushed, up to a full interval if polled. The enforcement point has to act on its session table. And if the teardown depends on the endpoint's tunnel client, the client has to be awake, online and reachable; a laptop suspended in a bag learns nothing until it wakes.
- What should you do before you run a wide revocation across a large remote workforce?Know the predicate's blast radius — how many live sessions it matches — and tell the people who will absorb it: the service desk, and the owners of any long-running job you are about to kill. Then have a re-admission path ready, because everyone you dropped will try to come back within the same few minutes.
Cancelling someone's building pass stops them getting through the turnstile again; it does not eject the person already sitting in the meeting room. Somebody has to walk in and ask them to leave.
saying these in an interview costs you the question
- Says disabling the account terminates live connections
- Treats credential expiry as if it were revocation
- Assumes zero trust means every packet is authorised individually
- Cannot name who else gets disconnected by the same rule
- Thinks an idle timeout will close the flow despite keepalives