# Authentication Guidance & Hardening (Comprehensive, EU‑Aligned)

**Document owner:** [Owner/Role]  
**Approved by:** [Steering Committee / CISO]  
**Effective date:** [YYYY-MM-DD]  
**Review cadence:** [Annually]

---

## 1. Purpose & Scope
This document provides practical guidance and examples for implementing the Authentication Policy across [Organization] systems.  
It includes detailed examples for assurance levels, distinction of methods (passwords vs PINs vs biometrics), special cases (BitLocker, local admin accounts), out‑of‑band methods, central vs. local authentication, and reauthentication.

---

## 2. Method Identification Guide (What is it? Where does the secret live?)
Use this section to classify any method you encounter.

### 2.1 Memorized Secrets (Passwords)
- **What it is:** A human‑chosen **password** sent to a **verifier** (server) that stores only a **hash**.  
- **Where the secret lives:** In the **user’s memory**; verifier stores a **hashed verifier**.  
- **Factor category:** **Something you know**.  
- **Typical AAL:** **AAL1** alone; **AAL2** when combined with another factor.  
- **Examples:** Account password for SSO, VPN, app logins.  
- **Notes:** Allow paste/managers; use passphrases; blocklist screening; no composition rules; no periodic expiry.

### 2.2 Activation Secrets (PINs that unlock local authenticators)
- **What it is:** A **PIN** used to unlock a **local cryptographic key** (TPM, smart card, FIDO2). The PIN itself is **never transmitted** to a server.  
- **Where the secret lives:** **On the device/token** only (e.g., TPM/smart‑card); verifier never sees it.  
- **Factor category:** **Something you know** (used locally), combined with **something you have** (device/token).  
- **Typical AAL:** Contributes to **AAL2** or **AAL3** depending on hardware and protocol.  
- **Examples and distinctions:**  
  - **Windows Hello PIN** → unlocks TPM‑bound private key on **that device only**; **not** the same as the account password.  
  - **Smart‑card PIN** → unlocks card’s private key; used with certificate‑based login.  
  - **FIDO2 PIN** → unlocks the authenticator to perform WebAuthn challenges.  
  - **Mobile device screen PIN** → unlocks the phone; when used with a bound authenticator app, it protects the **OOB** channel.  
  - **BitLocker pre‑boot PIN** → unlocks the disk key (see BitLocker section).  
- **Minimums:** PIN **≥4**, **should be ≥6**; local throttling/lockout required.

### 2.3 Biometrics (Local unlock only)
- **What it is:** **Fingerprint/face/iris** used to unlock a **local key** (e.g., Windows Hello, phone biometric).  
- **Where the secret lives:** Biometric template stays on the device/TPM/secure enclave.  
- **Factor category:** **Something you are** (local unlock).  
- **Typical AAL:** Part of **AAL2/AAL3** when combined with hardware key; **never** as sole factor.

### 2.4 Out‑of‑Band (OOB) Methods
- **What it is:** A second, **separate channel** (e.g., mobile app) to approve login.  
- **Where the secret lives:** Bound to the **mobile device/app**; approvals sent over encrypted channel.  
- **Factor category:** Typically **something you have** (the device), sometimes plus its **PIN/biometric** (something you know/are).  
- **Typical AAL:** **AAL2** when **device‑bound and encrypted**.  
- **Examples:** Push approvals; **QR‑code sign‑in** with Microsoft Authenticator.  
- **Not permitted as primary:** SMS/voice/email (recovery only).

---

## 3. Assurance Levels – Examples & Guidance

### 🔹 AAL1 (Single Factor)
- **Examples:**  
  - Password‑only login to low‑risk intranet site  
  - Local Linux/Windows account with password  
  - BitLocker with **PIN only** (no TPM)  
  - Local admin password **without LAPS**  
- **Risks:** Phishable/replayable; brute‑forceable.  
- **Guidance:** Use only for low‑sensitivity or offline recovery; **not** for remote/external access; plan deprecation.

### 🔹 AAL2 (Standard MFA)
- **Examples:**  
  - Password + **TOTP** authenticator app  
  - Password + **push** approval on a bound device  
  - Password + **QR‑code** sign‑in with Microsoft Authenticator  
  - **Smart‑card + PIN**  
  - **Windows Hello** (TPM‑backed key) + PIN/biometric  
  - **BitLocker: TPM + PIN**  
  - Local admin password **with LAPS** (unique per device, rotated) for offline recovery scenarios  
- **Risks:** Still phishable (push/QR can be proxied).  
- **Guidance:** Default for SaaS, VPN, employee desktops; allow push/QR only when **device‑bound** and **rate‑limited**; enroll **≥2 MFA methods** per user.

### 🔹 AAL3 (High Assurance)
- **Examples:**  
  - **FIDO2/WebAuthn hardware** security key  
  - **PIV/smart‑card** login with crypto challenge + PIN  
  - **Windows Hello** with biometric unlocking a **TPM‑bound** key used for hardware‑backed auth  
  - **BitLocker: TPM + PIN + post‑boot FIDO2** login  
- **Risks:** Strong phishing and verifier‑impersonation resistance.  
- **Guidance:** Required for admins, production, regulated systems; **no OOB**; keys must be **non‑exportable** and hardware‑protected; biometrics only unlock keys.

---

## 4. Central vs. Local Authentication
- **Central (preferred):** IdP/SSO (SAML/OIDC/RADIUS) with consistent policy, logging, and conditional access.  
- **Local (supporting/offline):** BitLocker pre‑boot PIN, Windows Hello PIN, Linux root password.  
- **Guidance:** Local methods **must** follow length/blocklist rules for memorized secrets and enforce local throttling; prefer TPM/smart‑card integration for higher assurance.

---

## 5. BitLocker Pre‑Boot Authentication (Deep‑dive)
- **TPM only:** Disk key released automatically → **AAL1**. Not acceptable for sensitive data.  
- **PIN only (no TPM):** PIN protects disk key → **AAL1**. Use only with compensating **post‑boot MFA** and limited roles.  
- **TPM + PIN:** PIN unlocks TPM which releases disk key → **AAL2**. Enterprise baseline for laptops.  
- **TPM + PIN + post‑boot FIDO2/smart‑card:** Meets **AAL3** for privileged/regulated systems.  
- **Operational requirements:** PIN length **≥6** recommended; enforce lockout/anti‑hammering; maintain recovery key hygiene; test pre‑boot accessibility for users with assistive tech.

---

## 6. Local Administrator Accounts
- **Without LAPS:** Shared/static password → **AAL1 (high risk)**; prohibited except as break‑glass in a vault with approvals and audit.  
- **With LAPS:** Unique random password per device, rotated automatically → **AAL1 (mitigated)**; acceptable for offline recovery; retrieval must be logged.  
- **Preferred daily admin:** Central privileged accounts with **MFA** (**AAL2/AAL3**).

---

## 7. Reauthentication & Session Management
- **AAL1:** Reauth **≤ 30 days**.  
- **AAL2:** Reauth **≤ 24 hours**, inactivity **≤ 1 hour**.  
- **AAL3:** Reauth **≤ 12 hours**, inactivity **≤ 15 minutes**.  
- **Tips:** Warn prior to expiry; support seamless reauth with device‑bound authenticators.

---

## 8. Password Creation & User Education (Quick Guide)
- Prefer **passphrases** (multiple unrelated words with spaces).  
- Avoid personal info, service names, or keyboard patterns.  
- Use a **password manager**; unique secret per site/system.  
- Expect **blocklist rejection** for weak/compromised choices.  
- Do **not** write down passwords in plain sight; if written, store securely.

---

## 9. Quick Comparison Tables

### 9.1 Method Classification
| Method | What it is | Secret location | Factor(s) | Typical AAL | Notes |
|---|---|---|---|---|---|
| Account **password** | Memorized secret sent to verifier | User memory / verifier stores hash | Know | AAL1 (alone) | Needs blocklist; no composition; no expiry |
| **Windows Hello PIN** | Local PIN to unlock TPM key | Device TPM | Know + Have (device) | AAL2–AAL3* | Device‑specific; not account password |
| **Smart‑card PIN** | Local PIN to unlock card key | Smart‑card | Know + Have | AAL2–AAL3 | Cert‑based login |
| **FIDO2 PIN** | Local PIN to unlock FIDO key | Hardware key | Know + Have | AAL3 | Phishing‑resistant |
| **Biometric** | Local unlock (face/fingerprint) | Device enclave | Are (+ Have) | AAL2–AAL3 | Unlock only; not sole factor |
| **TOTP app** | One‑time code generator | Mobile device | Have (+ Know if app PIN) | AAL2 | Bind device; protect seed |
| **Push/QR OOB** | Encrypted approval channel | Mobile device | Have (+ Know/Are) | AAL2 | Device‑bound & rate‑limited |
| **SMS/voice/email OTP** | Code over PSTN/email | Network/mail | Have? (weak) | Recovery only | Not primary MFA |

\*Depends on deployment: with hardware‑bound non‑exportable keys and phishing‑resistant protocol usage, Windows Hello deployments can reach AAL3.

### 9.2 BitLocker Summary
| Mode | AAL | Use Case | Notes |
|---|---|---|---|
| TPM only | AAL1 | Low‑risk fleets | Not for sensitive data |
| PIN only (no TPM) | AAL1 | Legacy/no‑TPM | Must pair with post‑boot MFA |
| TPM + PIN | AAL2 | Enterprise baseline | Enforce ≥6 PIN, anti‑hammering |
| TPM + PIN + post‑boot FIDO2 | AAL3 | Admin/regulated | Strongest posture |

---

## 10. Hardening Checklist
✅ Map systems to **AAL1–AAL3**  
✅ Enforce **password** rules (length, 64‑char support, Unicode, blocklist, no composition)  
✅ Enroll **≥2 MFA methods** per user (primary + backup)  
✅ Prefer **FIDO2/smart‑card** for AAL3; ban **OOB** at AAL3  
✅ Permit only **device‑bound encrypted** push/QR; **ban SMS/email/voice** as primary  
✅ Enforce **LAPS** on all Windows endpoints; ban shared local admin passwords  
✅ Configure **rate‑limiting** for online guesses; local anti‑hammering for PINs  
✅ Implement **session timeouts** per AAL; warn users pre‑expiry  
✅ Audit **MFA resets**, **local admin retrievals**, and **failed logins**  

---

## 11. Account Type × TLP Sensitivity — Worked Examples
Normative minimums are in Policy §§3–4. Governing AAL = **max(account-type minimum, data-sensitivity minimum)**.

| Scenario | Account Type Min | TLP of Data Touched | Data Min | Governing AAL |
|---|---|---|---|---|
| Helpdesk agent reading public knowledge base | Standard User → AAL2 | TLP:CLEAR → AAL1 | — | **AAL2** (account floor wins) |
| Finance analyst opening internal budget doc | Standard User → AAL2 | TLP:GREEN → AAL2 | — | **AAL2** |
| HR admin accessing employee PII export | Privileged/Admin → AAL3 | TLP:AMBER → AAL2 (AAL3 for admin) | — | **AAL3** |
| Domain admin managing DCs | Privileged/Admin → AAL3 | TLP:AMBER+STRICT → AAL3 | — | **AAL3**, no OOB |
| SOC analyst pulling active incident IOCs shared by a partner | Standard User → AAL2 | TLP:RED → AAL3 | — | **AAL3** (data floor wins over account floor) |
| CI/CD pipeline pulling build artifacts | Service/Machine → N/A | TLP:GREEN → AAL2 | — | Not applicable — no interactive auth; use managed identity/certificate per §3 |
| Vendor support engineer troubleshooting a ticket | Third-party → AAL2 | TLP:AMBER → AAL2 | — | **AAL2**, time-bound |
| On-call engineer invoking break-glass domain admin during MFA outage | Break-glass → AAL2 min | TLP:AMBER+STRICT → AAL3 | — | **AAL3 preferred**, but checkout proceeds at AAL2 minimum with mandatory post-incident review — see §3 |

**Rule of thumb:** never let a low-sensitivity account type "borrow down" the AAL required by high-sensitivity data, and never let low-sensitivity data waive the AAL an account type otherwise requires (e.g., admin accounts stay AAL3 even reading TLP:CLEAR content).

---

## 12. Antifragility — Practical Playbook
Concrete moves per pillar (policy clauses in parens):

- **Structural Decoupling (§2.6, §2.11):** Keep a written runbook for authenticating users if the IdP is down — e.g., break-glass local admin + offline MFA seed backup. Test it, don't just write it. Maintain a live doc: "if we had to leave [IdP vendor] in 90 days, here's the plan" — even if you never execute it.
- **Optionality Preservation (§2.4):** Don't let "MFA" mean "one app from one vendor." A FIDO2 key **and** a TOTP app satisfies §2.4 even if the authenticator app vendor has an outage. Enrollment flow should force both before granting access.
- **Stress-to-Signal Conversion (§2.12, §2.13):** Log every MFA fatigue/push-bombing attempt as an incident, not noise — recurring pattern with no policy change is a finding. Break-glass drill format: non-prod first, read-only check before destructive, one account before many, written abort trigger ("if X happens, stop and roll back") agreed before starting.
- **Sovereign Intelligence (§2.14):** One-page "if the IdP admin got hit by a bus" doc: where Conditional Access rules live, who has break-glass credentials, how MFA vendor is configured. Named owner, reviewed at least yearly.
- **Asymmetric Payoff / Barbell (§2.1, §3):** Resist the urge to apply AAL2.5-ish "extra effort" everywhere. Kill-chain systems (IdP, PKI root, backup infra, break-glass vault) get AAL3 + extra scrutiny, full stop. Everything else gets the AAL2 baseline and no more — spending moderate effort broadly instead of concentrating it on kill-chain nodes is the failure mode this pillar exists to prevent.

---

## 13. References
- [NIST SP 800‑63B (Digital Identity Guidelines, 2023 update)](https://pages.nist.gov/800-63-3/sp800-63b.html)  
- [CIS Controls v8.1 (Controls 5 & 6)](https://www.cisecurity.org/controls/v8-1)  
- [ENISA Digital Identity and Data Protection](https://www.enisa.europa.eu/topics/digital-identity-and-data-protection)  
- [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)