Zero Trust Access Simulator

1. Zero Trust in plain language

Zero Trust does not mean "trust nobody forever." It means that network location or device ownership alone should not create implicit trust. Each access request is evaluated using identity, device, resource, policy, environmental, and threat/risk information.

NIST concept: protect resources rather than relying primarily on a network perimeter. Authentication and authorization of the subject and device occur before access to an enterprise resource is established.

Important: this simulator uses a transparent scoring and rules engine for teaching. NIST SP 800-207 does not mandate the exact score, thresholds, MFA types, patch-age limits, or four outcome labels used here. Those are configurable educational policy choices.

Core question

Should this request be permitted now?

Who?Which device?What resource?What action?What context?What risk?

Four simulated outcomes

ALLOW
Policy requirements are satisfied.

DENY
Authorization or a hard-block rule fails.

QUARANTINE
The endpoint/session appears dangerous and is restricted.

REMEDIATION
A fixable posture or authentication condition must be corrected.

2. Logical architecture

This animation mirrors the broad NIST SP 800-207 model: a Policy Engine (PE) makes the access decision; a Policy Administrator (PA) acts on that decision; and a Policy Enforcement Point (PEP) enables, monitors, or terminates the connection.

SubjectUser + device request

PEPPolicy Enforcement Point

Policy EngineDecision logic

Policy AdministratorExecutes decision

Enterprise ResourceApp / API / data

Identity SignalsUser, role, MFA, session

Device SignalsPatch, EDR, cert, encryption

Threat IntelligenceRisk, travel, malicious IP

Enterprise PolicyRole, resource, action, thresholds

Real implementations can combine identity providers, endpoint management, EDR, PKI, SIEM/UEBA, data classification, network telemetry, threat feeds, gateways, service meshes, and other systems.

3. Scenario presets

Start with a preset, then modify individual signals in the request builder.

4. Build the access request

A. IdentityUser statusIdentity / roleAuthenticationMFA methodUser risk score: 15/100

B. Device postureManagement stateEndpoint securityPatch age: 7 daysFull-disk encryption enabledSecure Boot / integrity check passesDevice certificate

C. ContextLocationNetworkBehaviorThreat intelligenceSession age: 15 minutes

D. Resource requestResourceRequested actionResource sensitivity

E. Request preview

5. Policy-engine simulation

1 - SubjectIdentity and authentication

2 - DevicePosture and certificate

3 - ContextLocation and threat signals

4 - AuthorizationResource + requested action

5 - DecisionPE to PA to PEP

Calculated request risk

- / 100

Educational composite score. Lower is better. Detailed policy rules determine the outcome.

READY

Configure a request and run the policy engine.

Policy checks

?

Waiting for evaluation

-

Decision/event log

[SIM] Zero Trust policy engine ready.
[SIM] No implicit trust is granted by network location.

6. Continuous evaluation

Zero Trust is not merely a login-time decision. Changing telemetry can cause a session to be re-evaluated or terminated. First obtain an ALLOW decision, then inject an event.

Session telemetry: no event injected yet.

7. Policy lab: change the organization's rules

Security policy determines how signals become an access decision. Change thresholds, rerun the same request, and observe how policy - not merely technology - changes the result.

Maximum patch age: 30 daysHard-deny risk threshold: 80

Step-up/remediation threshold: 55Maximum session age: 240 min

Require managed device for High/Critical dataRequire phishing-resistant MFA for admin actionsRequire valid device certificate for High/Critical dataBlock restricted/high-risk regions for High/Critical data

Teaching point: Zero Trust is a policy architecture, not a single product. The Policy Engine needs enough context to determine whether the subject may perform the requested action on the resource under current conditions.

8. Device certificate explorer

A certificate can provide a cryptographically verifiable device or workload identity signal. A certificate does not, by itself, prove that the endpoint is fully healthy or that the user is authorized to access every resource.

Questions the policy system can ask

Issuer trusted?Chains to an accepted CA?

Time valid?Within validity period?

Revoked?CRL/OCSP or equivalent?

Identity match?Bound to expected device?

Key use?Appropriate EKU/purpose?

Do not conflate certificate validity with device posture. A valid certificate can coexist with missing patches or active malware unless separate telemetry and policy evaluate those conditions.

9. Guided student laboratories

Lab 1 - Why "inside the network" is not enough

Load Healthy Employee. Change only the network from Home to Public Wi-Fi and run it. Then change the user to a disabled account and rerun.

Question: Why should network location alone neither grant nor deny access?

Lab 2 - MFA strength and privileged access

Load Privileged Admin Access. Compare no MFA, SMS, TOTP, push, and FIDO2/security-key authentication while keeping the action unchanged.

Lab 3 - Remediation vs quarantine

Load Out-of-Date Laptop and observe the result. Then load EDR Malware Alert. Explain why the two conditions can justify different responses.

Lab 4 - Certificate is not the same as "clean"

Start with a valid certificate and healthy device. Change EDR to Active Malware Alert without changing the certificate. Rerun and explain the result.

Lab 5 - Resource sensitivity changes policy

Keep the same subject and device. Request Employee Email and then Restricted Defense Project Data. Explain why stronger conditions may be justified for the latter.

Lab 6 - Continuous evaluation

Start a clean session that receives ALLOW. Inject Bulk Download. Reset, then inject an EDR malware alert. Compare the resulting controls.

Lab 7 - Write your own policy

Design one strict defense-contractor policy and one university general-computing policy using the sliders and checkboxes. Find one request where they produce different outcomes.

10. Ten-question knowledge check

11. Authoritative references and further reading

Source	Why it matters	Link
NIST SP 800-207 - Zero Trust Architecture	Foundational U.S. federal reference defining Zero Trust concepts, tenets, logical components and deployment approaches.	NIST CSRC
NIST SP 800-207A	Zero Trust access control for cloud-native applications and multi-cloud environments.	NIST CSRC
NIST NCCoE - Implementing a Zero Trust Architecture	Implementation-oriented practice guide and example architectures.	NIST NCCoE
CISA Zero Trust Maturity Model	Identity, Devices, Networks/Environments, Applications/Workloads, Data, and cross-cutting capabilities.	CISA
DoD Zero Trust Strategy and Roadmap	Department of Defense strategy for operationalizing Zero Trust.	U.S. Department of Defense
Google BeyondCorp	Influential user- and device-aware access model that does not rely on a traditional trusted network perimeter.	Google Cloud