# Zero Trust decisions and identity incident response

Assess resource, identity and context instead of trusting network location. Track token scope and application outcomes during identity incidents.

Original AI-assisted SecNet educational content. Fictional local examples; not a standards provider publication, endorsement or compliance evidence. Page exercises do not create account progress.

Sources checked: 2026-10-21

## Zero Trust is not a product label

NIST SP 800-207 describes resource-focused trust decisions; presence on an enterprise network alone supplies no trust. Design decision and enforcement points using identity, device, resource and relevant context. A VPN may be one safeguard but does not authorize every resource. Harbor uses device context as a declared evidence field, not an actual health check. This lesson delivers no complete Zero Trust architecture, maturity rating or certification. Learners explain which resource and risk a decision addresses instead of treating a purchased product or network location as universal assurance.

## The boundary that enforces the decision

A policy engine’s deny does not end access if the target never enforces it. Assess signal sources, decision latency, error behavior and audit records together. Do not assume every system supports continuous immediate revocation. Harbor’s desk computes a fixed-time file-based decision; it is not a live enforcement point. Authorized owners assess operational effects of restrictions on critical work. Scoped negative tests can provide stronger boundary evidence than demonstrations of the successful path alone. The model does not contact a provider or alter an application policy.

## Scope and authority during identity incidents

For suspicious access, examine user and workload identities, consent, tokens and application sessions separately. Password changes or a central block alone do not close the incident. Authorized responders plan business effects, evidence and target-outcome verification. Record provider-specific revocation delays and ownership of application sessions. Harbor ends no actual sessions and creates no incident record. Learners separate supported observations from hypotheses and explain why establishing new credentials does not necessarily terminate old access. Response scope must follow the affected trust paths rather than one successful central action.

## Measure improvement through control evidence

A dashboard or blocked-sign-in count does not alone demonstrate coverage and correctness. Show included applications, excluded paths and what negative tests establish. Harbor links control ownership, resource inventory, decision design and outcome testing. Track exceptions through expiry and accountability. Success means necessary work remains bounded and traceable, not indiscriminate automatic blocking. Exercises on this page write no account points, exam results or credentials. Actual competency assessment and organizational assurance require separate evidence beyond correct answers in an educational model.

## Working sequence

1. Define the resource and trust decision.
2. Record identity, device and application signal limits.
3. Separate the decision from actual enforcement.
4. Review incident and revocation scope with authorized owners.
5. Record negative tests, gaps and the next improvement.

## 1. Trusted because it is on the VPN?

Network connectivity establishes no identity, device or resource-policy assurance. Assess context for the resource decision; Boolean flags are not actual device or network validation.

This code is a local policy model; it does not replace actual authentication, token validation or live permission tests.

### Weak implementation
```js
s => s.vpnConnected === true
```

### Corrected implementation
```js
s => s.vpnConnected === true &&
  s.identityVerified === true &&
  s.deviceContext === true &&
  s.resourcePolicy === true
```

### Synthetic input and actual model output
```json
{
  "before": [
    {
      "name": "documented-case",
      "input": {
        "vpnConnected": true,
        "identityVerified": true,
        "deviceContext": true,
        "resourcePolicy": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-deviceContext",
      "input": {
        "vpnConnected": true,
        "identityVerified": true,
        "deviceContext": false,
        "resourcePolicy": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    },
    {
      "name": "missing-resourcePolicy",
      "input": {
        "vpnConnected": true,
        "identityVerified": true,
        "deviceContext": true,
        "resourcePolicy": false
      },
      "expected": false,
      "observed": true,
      "matched": false
    }
  ],
  "after": [
    {
      "name": "documented-case",
      "input": {
        "vpnConnected": true,
        "identityVerified": true,
        "deviceContext": true,
        "resourcePolicy": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-deviceContext",
      "input": {
        "vpnConnected": true,
        "identityVerified": true,
        "deviceContext": false,
        "resourcePolicy": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    },
    {
      "name": "missing-resourcePolicy",
      "input": {
        "vpnConnected": true,
        "identityVerified": true,
        "deviceContext": true,
        "resourcePolicy": false
      },
      "expected": false,
      "observed": false,
      "matched": true
    }
  ]
}
```

## 2. Account blocked: close the incident?

A central block does not explain token scope and application outcomes. Without recovery ownership and validation evidence, termination of actual access remains unestablished.

This code is a local policy model; it does not replace actual authentication, token validation or live permission tests.

### Weak implementation
```js
s => s.accountBlocked === true
```

### Corrected implementation
```js
s => s.accountBlocked === true &&
  s.tokenScopeReviewed === true &&
  s.applicationOutcome === true &&
  s.recoveryOwned === true
```

### Synthetic input and actual model output
```json
{
  "before": [
    {
      "name": "documented-case",
      "input": {
        "accountBlocked": true,
        "tokenScopeReviewed": true,
        "applicationOutcome": true,
        "recoveryOwned": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-tokenScopeReviewed",
      "input": {
        "accountBlocked": true,
        "tokenScopeReviewed": false,
        "applicationOutcome": true,
        "recoveryOwned": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    },
    {
      "name": "missing-applicationOutcome",
      "input": {
        "accountBlocked": true,
        "tokenScopeReviewed": true,
        "applicationOutcome": false,
        "recoveryOwned": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    }
  ],
  "after": [
    {
      "name": "documented-case",
      "input": {
        "accountBlocked": true,
        "tokenScopeReviewed": true,
        "applicationOutcome": true,
        "recoveryOwned": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-tokenScopeReviewed",
      "input": {
        "accountBlocked": true,
        "tokenScopeReviewed": false,
        "applicationOutcome": true,
        "recoveryOwned": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    },
    {
      "name": "missing-applicationOutcome",
      "input": {
        "accountBlocked": true,
        "tokenScopeReviewed": true,
        "applicationOutcome": false,
        "recoveryOwned": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    }
  ]
}
```

## 3. Is a dashboard sufficient?

A dashboard supplies neither coverage nor negative tests. An owner must explain which boundary was validated by what evidence; the model generates no maturity score or Zero Trust approval.

This code is a local policy model; it does not replace actual authentication, token validation or live permission tests.

### Weak implementation
```js
s => s.dashboardExists === true
```

### Corrected implementation
```js
s => s.dashboardExists === true &&
  s.coverageKnown === true &&
  s.negativeTests === true &&
  s.decisionOwner === true
```

### Synthetic input and actual model output
```json
{
  "before": [
    {
      "name": "documented-case",
      "input": {
        "dashboardExists": true,
        "coverageKnown": true,
        "negativeTests": true,
        "decisionOwner": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-coverageKnown",
      "input": {
        "dashboardExists": true,
        "coverageKnown": false,
        "negativeTests": true,
        "decisionOwner": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    },
    {
      "name": "missing-negativeTests",
      "input": {
        "dashboardExists": true,
        "coverageKnown": true,
        "negativeTests": false,
        "decisionOwner": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    }
  ],
  "after": [
    {
      "name": "documented-case",
      "input": {
        "dashboardExists": true,
        "coverageKnown": true,
        "negativeTests": true,
        "decisionOwner": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-coverageKnown",
      "input": {
        "dashboardExists": true,
        "coverageKnown": false,
        "negativeTests": true,
        "decisionOwner": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    },
    {
      "name": "missing-negativeTests",
      "input": {
        "dashboardExists": true,
        "coverageKnown": true,
        "negativeTests": false,
        "decisionOwner": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    }
  ]
}
```

## Exit evidence

- Resource/decision/enforcement-point and signal-coverage matrix.
- Identity-incident, token-impact, validation and residual-risk record.

## References

- [NIST SP 800-207 · Zero Trust Architecture · Final August 2020](https://csrc.nist.gov/pubs/sp/800/207/final)
- [Microsoft Entra · Revoke user access and session limits](https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access)
- [RFC 9700 · OAuth 2.0 Security Best Current Practice · January 2025](https://www.rfc-editor.org/rfc/rfc9700.html)