Purpose of the Checklist
Traditional authentication methods, even multi-factor authentication (MFA), operate on a binary assumption: you're either authenticated or you're not. This model fails when AI-powered phishing bypasses MFA prompts, deepfakes fool biometric systems, and credential attacks occur in real time during active sessions.
This checklist provides a structured approach to implementing continuous identity trust controls that align with CISA's Zero Trust Architecture guidance and NIST SP 800-207. Use it to evaluate identity decisions continuously throughout a session, not just at login. Each check corresponds to a specific control you can implement with existing identity platforms, SIEM tools, and endpoint detection systems.
Government agencies face AI-driven identity threats that don't stop after initial authentication. Use this checklist during your next identity architecture review or when planning your Zero Trust roadmap.
Prerequisites
Before applying this checklist, ensure you have:
- Phishing-resistant MFA deployed across privileged accounts and sensitive systems (FIDO2, PIV/CAC, or certificate-based authentication)
- Centralized identity provider with API access for policy enforcement (Azure AD, Okta, Ping, or SailPoint)
- SIEM or log aggregation capable of ingesting authentication events, endpoint telemetry, and network flow data
- Baseline identity behavior data for at least 30 days (normal login times, device fingerprints, access patterns)
- Defined data classification so you know which systems require continuous trust evaluation versus static authentication
If you're still using SMS-based MFA or lack centralized logging, address those gaps first. Continuous trust requires actionable telemetry.
The Checklist
Copy this into your identity security runbook. Customize the frequency column based on your risk tolerance and system sensitivity.
Session Initiation Controls
☐ Verify authentication method strength
Check: Did the user authenticate with phishing-resistant MFA?
Action if no: Require step-up authentication before granting access to classified or sensitive unclassified systems.
Frequency: Every new session
☐ Validate device posture
Check: Is the endpoint compliant (patched, encrypted, EDR active)?
Action if no: Restrict access to read-only or deny entirely.
Frequency: Every new session
☐ Confirm geolocation consistency
Check: Does the login location match the user's typical pattern or approved locations?
Action if no: Trigger MFA re-prompt or flag for manual review.
Frequency: Every new session
Continuous Session Monitoring
☐ Monitor for impossible travel
Check: Has the user authenticated from two locations that are geographically impossible within the session timeframe?
Action if yes: Terminate session immediately and require re-authentication.
Frequency: Real-time during active sessions
☐ Detect behavioral anomalies
Check: Is the user accessing systems, files, or data outside their normal pattern (time of day, volume, resource type)?
Action if yes: Step down privileges or require re-authentication for sensitive actions.
Frequency: Continuous (5-15 minute intervals)
☐ Validate device consistency
Check: Has the device fingerprint changed mid-session (browser, OS, hardware token)?
Action if yes: Assume potential session hijacking; terminate and require full re-authentication.
Frequency: Every 10 minutes for high-privilege sessions
☐ Check for concurrent sessions
Check: Is the same user authenticated from multiple devices simultaneously when policy prohibits it?
Action if yes: Terminate older session or both sessions depending on risk policy.
Frequency: Real-time
Privilege and Access Re-Evaluation
☐ Re-verify before sensitive actions
Check: Is the user attempting to access classified data, modify configurations, or export large datasets?
Action: Require MFA re-prompt or biometric confirmation before allowing the action.
Frequency: Per-action for high-risk operations
☐ Enforce time-based access limits
Check: Has the session exceeded the maximum duration for the user's role (consider 8 hours for standard users, 4 hours for privileged accounts)?
Action if yes: Force re-authentication.
Frequency: Hourly checks
☐ Validate Just-in-Time Access expiration
Check: Was temporary elevated access granted, and has it expired?
Action if yes: Revoke privileges automatically; do not rely on manual removal.
Frequency: Real-time at expiration
Threat-Specific Indicators
☐ Scan for credential stuffing patterns
Check: Are there multiple failed login attempts followed by a successful authentication from the same IP or device?
Action if yes: Require password reset and phishing-resistant MFA re-enrollment.
Frequency: Real-time
☐ Detect deepfake or voice phishing indicators
Check: Did the user recently change MFA methods, recovery contacts, or privileged account settings after a help desk interaction?
Action if yes: Flag for manual verification; deepfake impersonation often targets help desk workflows.
Frequency: Daily review of account changes
☐ Monitor for lateral movement
Check: Is the user accessing systems or network segments outside their role requirements during an active session?
Action if yes: Reduce session privileges or terminate access pending investigation.
Frequency: Continuous (5-15 minute intervals)
Customization Tips
Adjust frequency based on data sensitivity. Systems handling classified information or personally identifiable information under the Privacy Act should trigger continuous checks every 5 minutes. Lower-sensitivity systems can extend to 15-30 minute intervals.
Map checks to your identity platform's capabilities. If you're using Azure AD Conditional Access, the "device posture" and "geolocation" checks map directly to Conditional Access policies. For Okta, use Behavior Detection rules and ThreatInsight. SailPoint users should configure IdentityIQ's certification campaigns to validate Just-in-Time Access expiration.
Integrate with your SIEM correlation rules. The "impossible travel" and "concurrent sessions" checks require cross-system telemetry. Configure your SIEM (Splunk, Sentinel, Chronicle) to correlate authentication logs with VPN logs and endpoint data. Create alerts that feed back into your identity provider's risk scoring.
Define your step-down and step-up actions. "Step down privileges" means revoking elevated access but maintaining basic session connectivity. "Step-up authentication" means requiring MFA re-prompt without terminating the session. Document which actions apply to which risk thresholds in your identity governance policy.
Align with your Zero Trust maturity model. If you're at CISA's Zero Trust Maturity Model Level 1 (Traditional), focus on session initiation controls first. At Level 2 (Advanced), implement continuous session monitoring. Level 3 (Optimal) requires real-time threat-specific indicators with automated response.
Validation Steps
After implementing these controls, validate they're working:
Run a tabletop exercise. Simulate an AI-powered phishing attack where an attacker has valid credentials but is accessing systems from an anomalous location. Verify your "geolocation consistency" and "behavioral anomaly" checks trigger correctly.
Test session termination. Have a user authenticate from one device, then attempt to continue the session from a different device with a different fingerprint. Confirm the "device consistency" check terminates the session.
Audit your SIEM correlation rules. Pull authentication logs for the past 7 days and manually check for impossible travel scenarios your automated rules might have missed. If you find gaps, refine your geolocation logic.
Review false positive rates weekly. Continuous trust controls will generate alerts. Track how many require manual review versus automated remediation. If more than 20% are false positives, adjust your behavioral baselines or tighten your device fingerprinting.
Verify Just-in-Time Access revocation. Grant temporary elevated access to a test account, wait for expiration, then attempt to use those privileges. Confirm access is denied without manual intervention.
Document your validation results in your System Security Plan if you're operating under NIST SP 800-53 or in your Authority to Operate package for FISMA systems. Continuous identity trust isn't a one-time implementation; it's an ongoing control that requires regular tuning.
