# MFA, recovery and session security

Look beyond an MFA-enabled label. Separate evidence for enrollment, identity recovery, phishing resistance and token/session termination.

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

## Second factors offer different assurance

MFA requires appropriate use of independent factors; two passwords are not two different factors. OTP and simple approval prompts do not offer the same properties as phishing-resistant cryptographic methods. Assess method selection against user and task risk, enrollment and recovery together. NIST SP 800-63B-4 supplies method and assurance context; this package certifies no AAL. Method labels in Harbor are evidence assumptions, not tests of actual devices or identity providers. Learners explain why a checked MFA box alone cannot demonstrate the intended level of protection.

## Enrollment and method changes

Strong sign-in does not suffice if an attacker can enroll their own authenticator. Initial enrollment, adding a device and removing an old method require appropriate identity checks and audit trails. Define what support staff may do and what evidence they need. Review compromise and social-engineering risks of recovery channels separately. Harbor records the request, verifying role and independent approval. It includes no real phone, biometric data or recovery codes and performs no actual authenticator binding. The evidence question concerns the process around the method, not just its product name.

## Password changes do not imply session termination

Passwords, refresh tokens, access tokens and application-owned cookies may have different lifecycles. Success of one operation does not demonstrate immediate loss of every access path. Record supported revocation behavior, timing and verification for each provider and application. Harbor asks for evidence concerning refresh capability and application sessions alongside a password change. It promises no universal instant session termination. During an actual incident, authorized teams assess user effects, recovery and verified target-application outcomes together instead of treating a central identity event as sufficient proof.

## Make recovery usable and accountable

Recovery should not permanently lock out legitimate users; evaluate emergency access and accessibility needs. Removing identity evidence for speed, however, defeats the control. Define approval ownership, audit records, appropriate user notification and misuse review. Do not store actual secrets or authentication codes as clear text in tickets. Harbor workpapers separate known facts, missing evidence and the person responsible for validating the outcome. A robust recovery process considers trusted end-to-end account use rather than merely increasing the number of available sign-in methods.

## Working sequence

1. Define user and task risk.
2. Separate method, enrollment and recovery evidence.
3. List token and session types.
4. Record revocation behavior and validation limits.
5. Record recovery ownership and open work.

## 1. MFA indicator

An MFA indicator establishes neither method suitability nor protected recovery. Review enrollment, method and recovery together before drawing an assurance conclusion.

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

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

### Corrected implementation
```js
s => s.mfaEnabled === true &&
  s.methodAppropriate === true &&
  s.enrollmentProtected === true &&
  s.recoveryReviewed === true
```

### Synthetic input and actual model output
```json
{
  "before": [
    {
      "name": "documented-case",
      "input": {
        "mfaEnabled": true,
        "methodAppropriate": true,
        "enrollmentProtected": true,
        "recoveryReviewed": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-methodAppropriate",
      "input": {
        "mfaEnabled": true,
        "methodAppropriate": false,
        "enrollmentProtected": true,
        "recoveryReviewed": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    },
    {
      "name": "missing-recoveryReviewed",
      "input": {
        "mfaEnabled": true,
        "methodAppropriate": true,
        "enrollmentProtected": true,
        "recoveryReviewed": false
      },
      "expected": false,
      "observed": true,
      "matched": false
    }
  ],
  "after": [
    {
      "name": "documented-case",
      "input": {
        "mfaEnabled": true,
        "methodAppropriate": true,
        "enrollmentProtected": true,
        "recoveryReviewed": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-methodAppropriate",
      "input": {
        "mfaEnabled": true,
        "methodAppropriate": false,
        "enrollmentProtected": true,
        "recoveryReviewed": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    },
    {
      "name": "missing-recoveryReviewed",
      "input": {
        "mfaEnabled": true,
        "methodAppropriate": true,
        "enrollmentProtected": true,
        "recoveryReviewed": false
      },
      "expected": false,
      "observed": false,
      "matched": true
    }
  ]
}
```

## 2. Should support reset it?

A support ticket is not identity evidence. Without verification, independent approval and audit records, recovery can become a path around otherwise strong sign-in controls.

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

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

### Corrected implementation
```js
s => s.ticketExists === true &&
  s.identityVerified === true &&
  s.independentApproval === true &&
  s.auditRecorded === true
```

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

## 3. Password changed: access ended?

A password change does not universally invalidate existing access tokens and application cookies immediately. Review revocation scope and application outcomes separately; the model terminates no real session.

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

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

### Corrected implementation
```js
s => s.passwordChanged === true &&
  s.refreshRevoked === true &&
  s.appSessionsReviewed === true &&
  s.outcomeVerified === true
```

### Synthetic input and actual model output
```json
{
  "before": [
    {
      "name": "documented-case",
      "input": {
        "passwordChanged": true,
        "refreshRevoked": true,
        "appSessionsReviewed": true,
        "outcomeVerified": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-refreshRevoked",
      "input": {
        "passwordChanged": true,
        "refreshRevoked": false,
        "appSessionsReviewed": true,
        "outcomeVerified": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    },
    {
      "name": "missing-appSessionsReviewed",
      "input": {
        "passwordChanged": true,
        "refreshRevoked": true,
        "appSessionsReviewed": false,
        "outcomeVerified": true
      },
      "expected": false,
      "observed": true,
      "matched": false
    }
  ],
  "after": [
    {
      "name": "documented-case",
      "input": {
        "passwordChanged": true,
        "refreshRevoked": true,
        "appSessionsReviewed": true,
        "outcomeVerified": true
      },
      "expected": true,
      "observed": true,
      "matched": true
    },
    {
      "name": "missing-refreshRevoked",
      "input": {
        "passwordChanged": true,
        "refreshRevoked": false,
        "appSessionsReviewed": true,
        "outcomeVerified": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    },
    {
      "name": "missing-appSessionsReviewed",
      "input": {
        "passwordChanged": true,
        "refreshRevoked": true,
        "appSessionsReviewed": false,
        "outcomeVerified": true
      },
      "expected": false,
      "observed": false,
      "matched": true
    }
  ]
}
```

## Exit evidence

- Method/enrollment/recovery assessment.
- Token and application-session outcome matrix.

## References

- [NIST SP 800-63B-4 · Authentication · Final July 2025](https://csrc.nist.gov/pubs/sp/800/63/b/4/final)
- [Microsoft Entra · Revoke user access and session limits](https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access)