# Authentication Policy (Comprehensive, EU‑Aligned) **Document owner:** [Owner/Role] **Approved by:** [Steering Committee / CISO] **Effective date:** [YYYY-MM-DD] **Review cadence:** [Annually] --- ## 1. Purpose & Scope This policy establishes mandatory requirements for authentication across [Organization] systems, including: - Passwords and memorized secrets - Multi‑factor authentication (MFA) - Authenticator Assurance Levels (AALs) - Out‑of‑band (OOB) authentication - Central vs. local authentication - Special cases (BitLocker, local admin accounts, device/smart‑card/mobile PINs) - Session management and reauthentication It is aligned with **NIST SP 800‑63B** (as best practice), **CIS Controls v8.1**, and **ENISA guidance**. It applies to all employees, contractors, vendors, and service accounts. This policy supports GDPR principles of **data protection by design** and **accountability**. --- ## 2. Policy Statements ### 2.1 Assurance Levels - [Organization] **shall** align with Authenticator Assurance Levels (AALs): - **AAL1:** Single‑factor authentication. Permitted only for low‑sensitivity internal apps or offline scenarios. - **AAL2:** Multi‑factor authentication combining two categories (e.g., password + OTP app, push, QR code OOB). Required for employee logins, SaaS, and external‑facing systems. - **AAL3:** High‑assurance, hardware‑backed MFA (e.g., FIDO2, smartcards). Required for privileged/admin access, production, and regulated data systems. - **Kill‑chain tier:** Systems whose compromise would be existential — the IdP itself, PKI/CA roots, backup and recovery infrastructure, the break‑glass vault — **must** be AAL3 with no exceptions. Protection is concentrated disproportionately here (barbell principle); do not spend equivalent effort hardening low‑value systems at the other end. ### 2.2 Memorized Secrets (Passwords) - **Length:** - **15+ characters** when used as a single factor. - **8+ characters** when used only in combination with MFA. - Systems **must** allow at least **64 characters**, accept **spaces/Unicode**, and **must not truncate** entered secrets. - **Composition:** No mandatory composition rules (no required mixes of upper/lower/digit/symbol). - **Screening:** New/changed passwords **must** be screened against **blocklists** of commonly used, expected, or **compromised** passwords (including organization‑specific terms). - **Expiration:** **No periodic expiration**. Change **only** upon suspected compromise or policy breach. - **Usability:** **Allow paste/autofill** and provide a **“show password”** option. **No password hints** and **no knowledge‑based questions (KBA)**. - **Reuse:** Password **must not** match the user’s current or any **of the last 5** passwords (where technically supported). - **Rate limiting:** Verifiers **must** throttle online guessing (progressive delays; avoid permanent lockout DoS). - **Storage:** Store only **salted, hashed** verifiers using **Argon2id (preferred)**, **bcrypt**, or **PBKDF2** with strong parameters; per‑credential unique salt; optional server‑side **pepper** protected separately. - **Transport:** Collect and transmit passwords only over **authenticated, encrypted channels** (TLS 1.2+). - **Managers:** Users **should** use an approved **password manager** to generate/store unique passwords. ### 2.3 Activation Secrets (Local Unlock PINs/Biometrics) - **Definition:** An **activation secret** (e.g., device PIN, Windows Hello PIN, smart‑card PIN, FIDO2 PIN) is used **only to unlock a local authenticator/TPM/smart‑card**. It is **not transmitted** to a server and is **not** a password. - **Requirements:** Activation secrets **shall** remain on the device/token; **shall be ≥4 characters** and **should be ≥6**; online guesses **shall** be throttled/limited locally. - **Biometrics:** May be used **only** to unlock a device‑bound key and **must not** be the sole authenticator. ### 2.4 Acceptable Authenticators - **Allowed:** FIDO2/WebAuthn keys; smartcards with PIN; authenticator apps (TOTP, push, **QR‑code sign‑in**); device‑bound biometrics (unlock only). - **Fallback only:** SMS/voice OTPs. - **Prohibited:** Email OTP; KBA/security questions. - **Vendor diversity:** Each user **must** enroll **≥2 MFA methods spanning at least two independent implementations** (e.g., a FIDO2 hardware key plus an authenticator app from a different vendor than the primary IdP's own). A single MFA vendor outage or compromise **must not** remove all of a user's factors. ### 2.5 Out‑of‑Band (OOB) Methods - OOB authenticators **must** use **encrypted, device‑bound** channels (e.g., push or QR‑code flows) and **must** implement rate‑limiting. - **SMS/voice/email** **must not** be used as **primary** MFA. SMS/voice may be used **only** as recovery with risk acceptance. ### 2.6 Central vs. Local Authentication - **Central IdP/SSO** **must** be the default for enterprise access. - **Local authentication** (device‑only) may be used for **pre‑boot**, **offline**, or **recovery**, but **must** meet the applicable AAL and other requirements in this policy. - **Graceful degradation:** The central IdP **must** have a documented, tested fallback authentication path for outage scenarios. An IdP with no fallback is a single point of failure for the entire organization; the fallback **must** be exercised at least annually. ### 2.7 BitLocker Pre‑Boot Authentication - **TPM only:** AAL1; not acceptable for sensitive systems. - **PIN only (no TPM):** AAL1; acceptable only with compensating controls. - **TPM + PIN:** AAL2; recommended baseline for enterprise laptops. - **TPM + PIN + post‑boot FIDO2/smart‑card MFA:** Meets AAL3 for administrative systems. ### 2.8 Local Administrator Accounts - Local admin accounts **must not** share passwords across devices. - **LAPS or equivalent** **must** randomize and rotate local admin passwords. - Local admin accounts **must not** be used for daily administration; use **central privileged accounts with MFA** (AAL2/AAL3). ### 2.9 Reauthentication & Session Management - **AAL1:** Reauthentication **≤ 30 days**. - **AAL2:** Reauthentication **≤ 24 hours**, inactivity timeout **≤ 1 hour**. - **AAL3:** Reauthentication **≤ 12 hours**, inactivity timeout **≤ 15 minutes**. ### 2.10 Enforcement - Violations **may** result in disciplinary action or revocation of access. - Non‑compliant systems **must** be remediated or formally excepted with CISO approval. ### 2.11 Vendor Exit Readiness - [Organization] **must** maintain a documented, current migration path off its primary IdP/MFA vendor, executable within **90 days** without loss of authentication capability. - This path **must** be reviewed **annually** and after any material change to the IdP/MFA vendor relationship. ### 2.12 Incident‑Driven Structural Learning - Every MFA bypass, credential‑stuffing event exceeding threshold, break‑glass invocation, or IdP outage **must** trigger a **blameless post‑mortem** producing **at least one structural change** (policy, architecture, or control) within **30 days**. - Structural findings **must** be tracked to closure; recurring root causes without a structural fix are a policy violation in themselves. ### 2.13 Break‑Glass Drills - Break‑glass procedures **must** be exercised at least **quarterly**, in a non‑production or scoped environment first, with a **pre‑agreed abort condition** and **bounded blast radius**. - Untested break‑glass access **is treated as broken access** — an unexercised emergency path is a liability, not a control. ### 2.14 Ownership & Documentation - Authentication architecture — IdP configuration, Conditional Access/policy rules, break‑glass procedure, MFA vendor configuration — **must** be documented in **owned, version‑controlled form** with a **named accountable owner**. - This knowledge **must not** exist solely as tribal knowledge held by one individual; loss of that individual **must not** mean loss of the organization's ability to operate or rebuild its authentication systems. --- ## 3. Account Type Requirements [Organization] recognizes the account types below. Each carries a **minimum** AAL; where an account also accesses data at a given TLP sensitivity (§4), the **higher** of the two minimums applies. | Account Type | Examples | Minimum AAL | MFA / Authenticator | Reauth / Inactivity | Special Controls | |---|---|---|---|---|---| | **Standard User** | Employee, contractor daily-use account | AAL2 | Password + TOTP/push/FIDO2 | ≤24h / ≤1h | Standard joiner/mover/leaver process | | **Privileged / Admin** | Domain admin, cloud admin, DBA, security admin | AAL3 | FIDO2/WebAuthn or smart‑card; no OOB | ≤12h / ≤15min | Separate from daily-use account; JIT/PIM elevation; fully logged | | **Service / Machine / API** | Automation, CI/CD, application-to-application | N/A (non-interactive) | Certificate, managed identity, or vaulted key | N/A | No interactive login; automated rotation; no shared use across services | | **Break-glass / Emergency** | Emergency domain admin, DR access | AAL2 minimum, AAL3 preferred | Vaulted credential, MFA required at checkout | Time-bound, single-use | Sealed in PAM vault; real-time alert on checkout; mandatory post-use audit and credential rotation | | **Third-party / Vendor** | MSP, external support, auditor with standing access | AAL2 (AAL3 if privileged or TLP:AMBER+STRICT/RED data) | Federated SSO preferred; MFA mandatory | Per role, per §2.9 | Time-bound access; contractually mandated MFA; offboarding SLA ≤ 24h from contract end | | **Guest / External Collaborator** | Partner, contractor without standing access | AAL2 | Federated identity or authenticator app | Session-bound to engagement | Requires internal sponsor; no standing/persistent access | | **Shared / Generic / System** | Legacy shared logins, kiosk accounts | **Prohibited** unless individually attributable | N/A | N/A | Requires documented exception, compensating controls, and CISO approval per §4 (Exceptions) | | **AI Agent (Autonomous)** | LLM-based agent, orchestrator, sub-agent, autonomous automation with tool/action access | N/A (credential-based) — governed by §3.1 capability scoping, not AAL alone | Short-lived/session-scoped credential; no static long-lived key | Task-scoped, expires at task completion | See §3.1 — this is not a Service Account with extra steps | ### 3.1 AI Agent Identity — Why It's Not a Service Account A **Service/Machine account** runs fixed code with an enumerable, static scope: you can audit exactly what it does before granting access. An **AI Agent** decides its action sequence at runtime from a prompt plus whatever tools/data it can reach — the scope is only enumerable as "the union of everything its tools allow," not as a fixed set of API calls. It also typically acts **on behalf of** a human or another agent, and can **spawn sub-agents**, neither of which a service account does. Treat it as a distinct account type with its own control model: - **Capability/tool-scoping is the privilege boundary, not role membership.** Least privilege for an agent means least *tools* and least *data reachable through those tools* — the tool/plugin/MCP-server allow-list **must** be reviewed and approved like any other permission grant (see [Access Control Policy §3.7](access_control_policy.md)). - **Delegation chain must be logged end-to-end.** Every agent action **must** log the full chain — invoking human/system → orchestrating agent → sub-agent → tool call → target system — not just "agent X did Y." See [Logging, Monitoring & Retention Policy §2.1](logging_monitoring_policy.md). - **No standing autonomous access to the kill-chain tier (§2.1).** Actions touching kill-chain systems **must** require human-in-the-loop approval per action; autonomy is permitted everywhere else within the agent's scoped capabilities. This is the barbell applied to agents. - **Sub-agents must not escalate privilege.** A spawned sub-agent's tool/data access **must** be a subset of its parent's — delegation narrows, never widens. - **Credentials must be short-lived and session/task-scoped**, per [Secrets & Key Management Policy §2.4](secrets_management_policy.md) — no static long-lived API key standing in for the agent indefinitely, the way a service account password might. - **Prompt injection is a modeled threat, not an edge case.** Untrusted content the agent consumes (web pages, documents, tool output, another agent's output) **must** be treated as a potential attacker-controlled input capable of hijacking the agent's actions *within its own legitimate permissions* — a confused-deputy attack, not a credential theft. Mitigations: tool allow-listing, human confirmation gates on high-risk actions, and treating "agent + untrusted content" as a trust-boundary crossing in threat models (see [Secure SDLC Policy §2.1](secure_sdlc_policy.md)). --- ## 4. Data Sensitivity Classification (TLP) [Organization] classifies information using the [FIRST.org Traffic Light Protocol (TLP) 2.0](https://www.first.org/tlp/) — full scheme and handling requirements defined in the [Data Classification & Handling Policy](data_classification_policy.md), the canonical source. Systems and accounts **must** meet the minimum AAL for the most sensitive TLP-classified data they can access; where this exceeds the account type's minimum in §3, the **higher** value governs. | TLP Level | Meaning | Minimum AAL | Additional Controls | |---|---|---|---| | **TLP:CLEAR** | Disclosure not limited (public) | AAL1 (org default AAL2 baseline per §2.1 still applies to logins) | None beyond baseline | | **TLP:GREEN** | Limited disclosure, community-wide | AAL2 | Standard MFA | | **TLP:AMBER** | Limited disclosure, organization + need-to-know | AAL2 (AAL3 for privileged/admin access) | Access logged; least privilege | | **TLP:AMBER+STRICT** | Limited disclosure, organization only, no further sharing | AAL3 | Phishing-resistant MFA mandatory; no OOB; quarterly access review | | **TLP:RED** | Named recipients only | AAL3 | Phishing-resistant MFA mandatory; no OOB; per-access approval; full audit trail; break-glass accounts excluded from standing access | --- ## 5. Antifragility Alignment This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**. Traceability from pillar to clause: | Pillar | Applied In | How | |---|---|---| | **1. Structural Decoupling** | §2.6, §2.11 | Documented IdP fallback path; 90-day vendor exit readiness — no single IdP/MFA vendor can hold the org hostage | | **2. Optionality Preservation** | §2.4, §2.9 | ≥2 MFA methods from independent implementations per user; ≥2 methods enrolled preserves the right to authenticate if one path fails | | **3. Stress-to-Signal Conversion** | §2.12, §2.13 | Every MFA bypass/outage/break-glass event forces a structural fix within 30 days; break-glass drilled quarterly with bounded blast radius and abort condition | | **4. Sovereign Intelligence** | §2.14, §3.1 | IdP config, Conditional Access rules, break-glass procedure documented and owned — not tribal knowledge held by one admin. An autonomous cloud-hosted agent with broad tool access is the sharpest form of the manifest's "AI leak" risk: it doesn't just process your data on infrastructure you don't control, it can **act** on it | | **5. Asymmetric Payoff Design (Barbell)** | §2.1 (kill-chain tier), §3 (Account Type table), §3.1 (agent kill-chain gate) | Paranoid AAL3 concentrated on kill-chain systems (IdP, PKI roots, backup infra, break-glass vault) and privileged accounts; standard AAL2 baseline elsewhere. Same logic applied to agents: human-in-the-loop mandatory at the kill-chain boundary, bounded autonomy everywhere else — nothing moderate in the middle | --- ## 6. 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)