---
title: "The Missing Piece of Zero Trust: Why Login-Time Verification Isn't Enough | Keystrike"
description: Zero trust assumes no implicit trust anywhere in the network. Yet most stacks still verify identity once, at login, and trust the session completely after that. Here's what NIST SP 800-207 and CISA's Zero Trust Maturity Model actually require, and where continuous validation fits.
---

[![Keystrike](https://lp.keystrike.com/hubfs/Group%201171275017%20(5).png)](https://keystrike.com)

<https://www.linkedin.com/company/keystrike/> [Free Assessment →](https://keystrike-remote-access-exposure.scoreapp.com/p/home)

Zero Trust Identity Security Session Governance

# The Missing Piece of Zero Trust: Why Login-Time Verification Isn't Enough

Zero trust architecture assumes no implicit trust anywhere in the network. Yet most zero trust stacks still verify identity once, at login, and trust everything that happens after that completely. Here's what NIST SP 800-207 and CISA's Zero Trust Maturity Model actually require of the identity pillar, and where the industry consistently stops short.

## The Moment Zero Trust Stops Trusting, and the Moment It Quietly Starts Again

A contractor logs into a privileged jump box Monday morning. MFA clears. Conditional access checks device posture, location looks normal, the session opens. For the rest of that session, nothing checks again whether the person typing commands is still the person who logged in.

Zero trust architecture exists specifically to remove blind spots like this one. The whole premise is that no user, device, or session gets trusted just because it already cleared a checkpoint. And yet, in most real deployments, that exact kind of implicit trust reappears a few minutes after login. It just moves from the network perimeter to the session itself.

## What NIST SP 800-207 Actually Requires

NIST SP 800-207 is the foundational U.S. guidance on zero trust architecture, and it is more specific about session-level trust than most vendor pitch decks give it credit for. Two of its seven core tenets deal directly with what should happen after a session opens, not just at the door.

Tenet 3 states that **"access to individual enterprise resources is granted on a per-session basis"** and that trust in the requester is evaluated before each grant, with authentication to one resource never automatically extending to another. Tenet 6 goes further: **"all resource authentication and authorization are dynamic and strictly enforced before access is allowed,"** describing this as **"a constant cycle of obtaining access, scanning and assessing threats, adapting, and continually reevaluating trust in ongoing communication."** The publication is explicit that continual monitoring, with possible reauthentication and reauthorization, should occur throughout user transactions, not solely at the initial handshake.

Wait, doesn't MFA already satisfy "dynamic authentication"?

MFA satisfies Tenet 6 at the moment of login. It does not satisfy the rest of the sentence. NIST describes reauthentication triggered by conditions like elapsed time, a new resource request, or anomalous activity, meaning the session is meant to be re-checked at intervals for as long as it runs. Most identity stacks implement the trigger-based version of this through conditional access policies. Between triggers, though, the session runs entirely on the trust established at login. That gap between triggers is exactly what Tenet 6 was written to close.

## Where CISA's Maturity Model Draws the Line

CISA's Zero Trust Maturity Model v2.0 turns NIST's tenets into a roadmap, scoring five pillars, including identity, across four stages: Traditional, Initial, Advanced, and Optimal. Each stage describes how far an organization has moved from login-time verification toward continuous validation.

CISA Zero Trust Maturity Model — Identity pillar progression

NIST 800-207 · 2020 CISA ZTMM v2.0 · 2023

login-time verification — where most stacks stall

Traditional

verify once, at login

Initial

some session context

Advanced

automated, login-anchored

Optimal

continuously validate

increasing maturity →

NIST SP 800-207 · Zero Trust Architecture

Access is granted on a per-session basis. Authentication and authorization are dynamic — a constant cycle of obtaining access, assessing threats, and continually reevaluating trust in ongoing communication.

CISA ZTMM v2.0 · Identity Pillar · Optimal

Continuous identity validation using real-time analysis, not just at the point access is initially granted.

Most stacks stall at login-time verification. The Optimal stage is where the session itself gets re-verified.

Traditional means verifying identity once, at login, with no further session context. Initial adds some session-level signal on top of that single check. Advanced automates the verification workflow, but it is still anchored to the login event; the automation happens faster, not more continuously. Optimal is the stage where identity is **continuously validated using real-time signals**, paired with access that is dynamically scoped to the specific action being taken, not granted in a single block at sign-in.

Most mature identity programs we see today sit at Advanced. SSO, automated MFA, and conditional access policies are in place, and that is genuine progress over a static VPN-and-password model. It is also, by CISA's own definition, one full stage short of what Optimal requires: verification that runs through the session, not just at the door.

What's actually different about the Optimal stage, beyond just "more automation"?

Advanced automates a login-time decision. Optimal treats identity as something to keep verifying for as long as the session is live. In practice, that means the question being answered is no longer "did the right credential log in," but "is the right human still the one acting, right now." Those are different questions, and most identity tooling on the market today is built to answer only the first one.

## The Session Is the Blind Spot Both Frameworks Already Named

None of this is theoretical. The gap between login-time verification and continuous validation is exactly where identity-based attacks now concentrate.

67%

of incidents investigated were rooted in identity-based attacks

Sophos Active Adversary Report, 2026

14 days

median attacker dwell time after initial compromise

Mandiant M-Trends, 2026

70%+

of organizations hit by at least one identity-related breach in the past year

Sophos, 2026

None of these figures describe a failed login. They describe what happens once a session is already open, already authenticated, and already trusted by every tool watching it. A login log confirms that a credential was accepted at 9:03 a.m. It has nothing to say about who was at the keyboard at 9:47, or whether that session was ever handed off, automated, or hijacked in between.

Zero trust was never really a login problem. NIST and CISA both wrote the harder requirement into the framework from the start: keep verifying identity for the life of the session, not just at the door.

## How to Get Zero Trust to Zero

Where Keystrike Fits

Keystrike supports the controls behind that continuous-validation requirement — sustained, cryptographic proof of human presence for every governed action inside a privileged session. It is supercharges your existing zero trust architecture, ensuring that you truly get zero trust to zero.

Keystrike operationalizes the Optimal stage of the identity pillar for privileged remote sessions. IAM, MFA, PAM, and ZTNA answer the login-time question well, and NIST and CISA both assume they are already in place. Keystrike answers the question those tools were never designed to ask: is a real, authorized human still behind every action inside a session that is already running.

- Continuous, cryptographic attestation that a physical human on an authorized device generated every command inside a governed session, not just the login.
- Live visibility into every active privileged session, with instant termination if attestation fails.
- Session evidence that maps directly to the continuous-validation language in NIST SP 800-207 and the Optimal stage of CISA's identity pillar, alongside IEC 62443, NERC CIP, and NIS2 requirements.
- Deployment on jump boxes and bastion hosts in under 20 minutes, with no agents on OT endpoints, PLCs, or HMIs, and no network re-architecture.

### See Where Your Identity Pillar Actually Sits

Book a 30-minute session with the Keystrike team. We'll walk through your current stack against the NIST and CISA continuous-validation requirements, and show you exactly what's covered and what isn't.

[Book Your 30-Minute Session →](https://calendly.com/donna-keystrike/strengthen-your-remote-access-governance)

## Frequently Asked Questions

What is NIST SP 800-207?

NIST SP 800-207 is the U.S. National Institute of Standards and Technology's foundational publication on Zero Trust Architecture. It defines zero trust through seven tenets, including that access is granted on a per-session basis (Tenet 3) and that authentication and authorization must be dynamic and continually reevaluated throughout a session, not just at login (Tenet 6).

What is the CISA Zero Trust Maturity Model?

CISA's Zero Trust Maturity Model v2.0 is a roadmap organizations use to assess progress toward zero trust across five pillars, including identity. Within the identity pillar, maturity runs through four stages: Traditional, Initial, Advanced, and Optimal, with Optimal defined by continuous, real-time identity validation rather than a single login-time check.

What's the difference between the Advanced and Optimal stages of the identity pillar?

Advanced automates identity verification but still anchors that verification to the login event. Optimal continuously validates identity for as long as a session runs, using real-time signals rather than checking once and trusting the rest of the session by default.

Does Keystrike replace MFA, IAM, or ZTNA?

No. MFA, IAM, and ZTNA verify identity and enforce policy at the point of login and at the network boundary. Keystrike governs what happens after that boundary is crossed, continuously verifying that a real, authorized human is still behind every action for the life of a privileged session.

Which compliance frameworks does Keystrike's session evidence map to?

Keystrike generates cryptographically attested session evidence that maps to the continuous-validation requirements in NIST SP 800-207 and CISA's Zero Trust Maturity Model, as well as IEC 62443 security zone requirements, NERC CIP requirements CIP-004, CIP-005, and CIP-007, and NIS2 continuous monitoring obligations.

Get Started

## Zero Trust Doesn't Stop at Login. Neither Should You.

Continuous, cryptographic proof of human presence inside every privileged session. Complements your existing IAM, PAM, and ZTNA stack. Closes the gap the frameworks already named.

[Sign Up for Free →](https://keystrike.com/trial)

Questions? [Email connect@keystrike.com](mailto:connect@keystrike.com)

[![Keystrike](https://lp.keystrike.com/hubfs/Group%201171275017%20(5).png)](https://keystrike.com)

<https://www.linkedin.com/company/keystrike/> [Free Assessment →](https://keystrike-remote-access-exposure.scoreapp.com/p/home)

© 2026 Keystrike. All rights reserved.

[Privacy Policy](https://keystrike.com/privacy) [Terms of Service](https://keystrike.com/terms) [Security](https://keystrike.com/security)