Files
policies/Security/authentication_policy.md

5.8 KiB
Raw Blame History

Authentication Policy (Comprehensive, EUAligned)

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
  • Multifactor authentication (MFA)
  • Authenticator Assurance Levels (AALs)
  • Outofband (OOB) authentication
  • Central vs. local authentication
  • Special cases (BitLocker, local admin accounts, device/smartcard/mobile PINs)
  • Session management and reauthentication

It is aligned with NIST SP 80063B (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: Singlefactor authentication. Permitted only for lowsensitivity internal apps or offline scenarios.
    • AAL2: Multifactor authentication combining two categories (e.g., password + OTP app, push, QR code OOB). Required for employee logins, SaaS, and externalfacing systems.
    • AAL3: Highassurance, hardwarebacked MFA (e.g., FIDO2, smartcards). Required for privileged/admin access, production, and regulated data systems.

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 organizationspecific 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 knowledgebased questions (KBA).
  • Reuse: Password must not match the users 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; percredential unique salt; optional serverside 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, smartcard PIN, FIDO2 PIN) is used only to unlock a local authenticator/TPM/smartcard. 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 devicebound key and must not be the sole authenticator.

2.4 Acceptable Authenticators

  • Allowed: FIDO2/WebAuthn keys; smartcards with PIN; authenticator apps (TOTP, push, QRcode signin); devicebound biometrics (unlock only).
  • Fallback only: SMS/voice OTPs.
  • Prohibited: Email OTP; KBA/security questions.

2.5 OutofBand (OOB) Methods

  • OOB authenticators must use encrypted, devicebound channels (e.g., push or QRcode flows) and must implement ratelimiting.
  • 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 (deviceonly) may be used for preboot, offline, or recovery, but must meet the applicable AAL and other requirements in this policy.

2.7 BitLocker PreBoot 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 + postboot FIDO2/smartcard 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.
  • Noncompliant systems must be remediated or formally excepted with CISO approval.

3. References

  • NIST SP 80063B (Digital Identity Guidelines, 2023 update)
  • CIS Controls v8.1 (Controls 5 & 6)
  • ENISA Guidelines on Identity and Access Management
  • OWASP Authentication Cheat Sheet