NIST SP 800-63B credential baseline
NIST SP 800-63B credential baseline
Frameworks · NIST SP 800-63B · v2026.06 · How Foundry’s authentication, MFA, and password posture maps to NIST SP 800-63B Authenticator Assurance Levels. Binding today. Last refreshed June 2026.
NIST SP 800-63B is the federal Digital Identity Guidelines for authentication and lifecycle management. Foundry’s credential policy adopts 800-63B as the binding baseline: passwordless by default, phishing-resistant MFA for privileged access, and a hard ban on SMS one-time codes for workforce. Patient-facing flows use email OTP where SMS would otherwise apply. See Access control for the operational policy.
Status Meets / exceeds Exceeds Meets (context-specific)
Authenticator Assurance Levels (AAL)
| AAL | 800-63B requirement (summary) | Foundry implementation | Status |
|---|---|---|---|
| AAL1 | Some assurance: single- or multi-factor authentication using approved authenticator types. | Public-marketing site (bioscopefoundry.com) and the patient OTP flow operate at AAL1-equivalent. No PHI is reachable at AAL1. | Meets (context-specific) |
| AAL2 | High confidence; two distinct authentication factors; replay resistance; approved cryptographic techniques. | Workforce access to consoles that support MFA is enrolled with the strongest factor each console supports, meeting AAL2. Doctor onboarding uses email magic links with short-lived, HttpOnly sessions and no PHI reach; the operating-platform workforce path will consolidate at AAL2 or higher once the production workforce IdP is wired (see ADR-011 in the conductor repo). | Meets (context-specific) |
| AAL3 | Very high confidence; hardware-based authenticator with verifier impersonation resistance (i.e., phishing-resistant); approved cryptography. | The AWS root account is enrolled today with a phishing-resistant WebAuthn passkey. A synced passkey is not a hardware-bound authenticator, so this meets AAL2 rather than AAL3; dedicated hardware security keys, which would satisfy AAL3’s hardware-bound requirement, are planned as sealed break-glass authenticators. Other privileged surfaces (IdP admin, production IaC apply, FHIR break-glass) are gated by the strongest factor each surface supports today; they will move toward hardware-bound authenticators as consoles adopt WebAuthn or as the workforce IdP is wired. | Meets (context-specific) |
Multi-factor authentication posture
| Audience / surface | Authenticator type | Effective AAL | Status |
|---|---|---|---|
| Workforce, standard access to the operating platform | Each console enrolled with the strongest MFA factor it supports today (TOTP or platform passkey); consolidation onto the production workforce IdP is tracked under ADR-011. | AAL2 per surface | Meets (context-specific) |
| Workforce, privileged / break-glass access (IaC, cloud admin, IdP admin) | AWS root: phishing-resistant WebAuthn passkey, enforced today per the account-setup runbook. Dedicated hardware security keys (hardware-bound, AAL3) are planned as sealed break-glass authenticators. Other privileged consoles: strongest factor available today, moving to WebAuthn as each surface supports it. | AAL2 on AWS root today; AAL2+ elsewhere | Meets (context-specific) |
| Physician providers, operating platform (v1 onboarding) | Email magic link with short-lived, HttpOnly session cookie. No PHI passes through the onboarding channel; PHI reach is gated by role and by the platform’s audited APIs. | AAL1 with role gating | Meets (context-specific) |
| Patients, operating platform (where supported) | Email one-time passcode by default; SMS OTP only where required by accessibility; magic-link discouraged for PHI surfaces. | AAL1 with step-up | Meets (context-specific) |
| Service accounts / workload identity | Short-lived workload identity tokens, no long-lived keys; secrets in a managed broker. | n/a (machine) | Meets / exceeds |
Memorized-secret rules (§ 5.1.1)
Foundry minimizes reliance on memorized secrets; workforce auth is passwordless. Where a memorized secret is unavoidable (e.g., a vendor SaaS without SSO), the following 800-63B rules apply.
| 800-63B requirement | Foundry implementation | Source | Status |
|---|---|---|---|
| Minimum length 8 characters; user-chosen secrets ≥ 8. | Minimum 14 characters for any workforce-managed memorized secret. | § 5.1.1.2 | Exceeds |
| Allow at least 64 characters; allow all printable ASCII and Unicode. | Length cap raised to at least 64; full character set allowed by the password manager. | § 5.1.1.2 | Meets / exceeds |
| Check against a breach corpus (compromised credentials). | All workforce memorized secrets are checked against a maintained breach corpus on set and on rotation. | § 5.1.1.2 | Meets / exceeds |
| No periodic rotation in the absence of compromise. | Routine periodic rotation is prohibited; rotation triggers are compromise, role change, or workforce departure. | § 5.1.1.2 | Meets / exceeds |
| No composition rules (e.g., “must contain a symbol”). | Composition rules are not imposed; length and breach-check do the work. | § 5.1.1.2 | Meets / exceeds |
| No password hints; no knowledge-based authentication. | Password hints are prohibited; KBA (“mother’s maiden name”, etc.) is not used as a recovery factor. | § 5.1.1.2 | Meets / exceeds |
| Rate limiting on the verifier. | Lockout / throttling configured at the identity provider; failed-attempt alerts are logged. | § 5.1.1.2 | Meets / exceeds |
| Salted hashing with a memory-hard function for stored secrets. | Foundry is passwordless in practice; where an application-stored password-bearing credential is required, argon2id is the required hash. Secrets at rest are never in source. | § 5.1.1.2 | Meets / exceeds |
Out-of-band / SMS authenticators (§ 5.1.3)
| 800-63B requirement | Foundry implementation | Source | Status |
|---|---|---|---|
| SMS-based OOB OTP is “restricted”: discouraged due to SIM-swap, SS7, and channel-binding risk. | SMS one-time codes are prohibited for the Foundry workforce, including providers using the operating platform. Patient flows prefer email OTP; SMS is used only where accessibility requires it and PHI is not in scope. | § 5.1.3.3 | Exceeds |
| Voice-over-PSTN OOB OTP is also restricted. | Not used. | § 5.1.3.3 | Exceeds |
Phishing-resistant authenticators (§ 5.1.7 & § 5.2.5)
| 800-63B requirement | Foundry implementation | Source | Status |
|---|---|---|---|
| AAL3 requires verifier-impersonation resistance (phishing resistance). | Phishing-resistant WebAuthn passkeys are the preferred factor and are enforced today on the AWS root account per its setup runbook; a synced passkey meets AAL2. Dedicated hardware-bound security keys, which would satisfy AAL3, are planned as sealed break-glass authenticators. Other privileged surfaces gate on the strongest factor each supports; they will migrate to WebAuthn as each console adopts it or as the workforce IdP is wired under ADR-011. | § 5.2.5 | Meets (context-specific) |
| Authenticator binding and replay resistance. | Where WebAuthn is enrolled today (AWS root), replay attacks are blocked by challenge-response. Dedicated hardware-bound keys are planned where device binding is required. Other surfaces rely on replay-resistant TOTP / push-with-number-matching where WebAuthn is not yet supported. | § 5.2.8 | Meets (context-specific) |
Session management (§ 7)
| 800-63B requirement | Foundry implementation | Source | Status |
|---|---|---|---|
| AAL2 reauthentication at least every 12 hours and after 30 minutes inactivity. | Operating-platform sessions enforce short idle and absolute timeouts; reauthentication is required at intervals at least as tight as 800-63B AAL2. | § 7.2 | Meets / exceeds |
| AAL3 reauthentication at least every 12 hours and after 15 minutes inactivity, with both factors. | Privileged sessions reauthenticate at least at the AAL3 cadence; idle timeouts are shorter for break-glass surfaces. | § 7.2 | Meets / exceeds |
Authenticator lifecycle & recovery (§ 6)
| 800-63B requirement | Foundry implementation | Source | Status |
|---|---|---|---|
| Authenticator binding at enrollment. | Workforce binding occurs at hire-time joiner workflow, verified by the hiring manager and the Security Officer’s delegate. | § 6.1 | Meets / exceeds |
| Loss, theft, or damage handling. | Same-day revocation; replacement authenticator issued after identity verification through a separate channel. | § 6.1.2 | Meets / exceeds |
| Account recovery does not weaken the assurance level. | Recovery from loss of all authenticators requires the same evidence as initial enrollment and a manager approval; no KBA fallback. | § 6.1.2 | Meets / exceeds |
| Authenticator expiration handling. | Where hardware authenticators are issued, they are inventoried in asset management with rotation triggers (firmware EOL, vendor advisory, departure). | § 6.1.3 | Meets / exceeds |
Why this baseline: a HIPAA business associate that hosts PHI in a healthcare-grade cloud and orchestrates clinic-scoped AI agents has a high-value credential surface. Phishing-resistant MFA for privileged access, paired with the FHIR-only PHI boundary, keeps a single phished credential from becoming a breach.