A user authenticates successfully in the morning. An hour later, the same session begins downloading large volumes of customer records from an unusual country. How does a zero trust architecture handle this?
Select an answer to reveal the explanation.
Short Explanation
Getting through airport security doesn't mean nobody watches you at the gate. Zero trust works the same way with continuous verification — a session that suddenly acts strange gets challenged or cut off. The trap is treating login as a one-time pass.
Full Explanation
Continuous verification means trust is never granted once and assumed for the rest of a session. A zero trust policy engine keeps evaluating signals such as behavior, location, data volume, device posture changes, and threat intelligence throughout the session. When activity deviates from the expected pattern, such as bulk downloads from an unusual country, the engine can respond by requiring step-up authentication, reducing privileges, or terminating the session through the enforcement point. This limits the window in which a hijacked session or stolen token can be abused. Continuing the session because trust was established at login describes the static model that zero trust replaces. Waiting until the next login allows the exfiltration to finish before any control applies. Zero trust does not limit itself to device posture; user and entity behavior, data access patterns, and risk scores are core inputs. Exam caveat: continuous evaluation depends on telemetry reaching the decision point, so session revocation mechanisms, such as token revocation and change of authorization, must be integrated rather than assumed. Operational check: simulate an anomalous action in a test session and confirm the policy engine logs a risk change and the session is challenged or terminated within the expected time.