Status: Accepted
Date: 2026-04-30
Deciders: Kristerpher (product owner), software-architect
Scope: Every web surface in the Raxx platform
Canonical reference doc: docs/security/auth-posture.md
Supersedes: informal per-surface decisions in docs/security/web-surface-posture.md
Context: PR #633 review thread (comment 2026-04-30 UTC) — Kristerpher asked for a clear, documented direction on how the platform is secured. PR #633 implements Class 3 and transitional Class 2 MFA at CF Access.
As of 2026-04-30, Raxx operates multiple surfaces for different audiences:
The authentication posture across these surfaces had grown incrementally without a unifying framework:
Kristerpher's directive from the PR #633 review: "Can we make sure we are clear on the direction on how our platform is secured?" This ADR captures that direction.
CF Access is for surface gating. App-level auth is for identity and capability. These are two distinct security layers, and both must be present on operator surfaces — even when their individual contributions overlap. The rationale: misconfiguration at one layer should not result in zero authentication.
Every Raxx surface belongs to exactly one class. Class determines the CF Access policy template and the app-auth requirement.
| Class | Description | CF Access role | CF MFA |
|---|---|---|---|
| 1 | Customer-facing public | None | N/A |
| 2 | Operator, strong app auth | Presence-only allowlist | Transitional: strong MFA until passkey GA; then presence-only |
| 3 | Operator, unaudited app auth | Allowlist gate | Strong MFA always (non-relaxable without replacing the tool) |
| 4 | Static internal (no app layer) | Sole auth | Strong MFA always (non-negotiable) |
Classification is documented and updated when surfaces are added or postures change. It is never implicit.
Once an operator surface reaches passkey GA (all operators enrolled, no non-passkey fallback, audit log complete), the CF Access MFA requirement is relaxed to presence-only. A phishing-resistant passkey already satisfies NIST SP 800-63B AAL2. Adding TOTP on top of that at the CF layer is friction without security gain.
This is not "less secure." It is the correct application of defense-in-depth: the strong factor is at the app layer (passkey, phishing-resistant, origin-scoped), and CF Access maintains the outer perimeter (identity allowlist, session management, origin guard).
The transition from Class 2 transitional to Class 2 target is not a silent infrastructure change. It requires:
require: [auth_method: "mfa"] to require: [].auth-posture.md) is updated to record the transition.Class 3 surfaces use third-party tools (Infisical, FreeScout) whose auth implementations are not audited at Raxx's standard. CF Access strong MFA compensates for this. The only path to relaxing Class 3 is replacing the surface with an internally-controlled, passkey-GA app — at which point it would graduate to Class 2.
Class 4 surfaces have no app layer at all. Removing CF Access would leave zero authentication. Strong MFA here is structural, not a policy choice.
auth-posture.md §6 is the canonical test for new surfacesAny new surface must be classified before deployment. The flowchart in auth-posture.md §6 is the authoritative procedure. The question "given who can see this and what app auth exists, what's the right CF Access posture?" is answered by walking the matrix, not by individual judgment.
console.raxx.app retains CF Access TOTP — Kristerpher must TOTP-enroll and carry an authenticator app. This is the correct transitional state, not a regression.auth-posture.md) are not yet enforced. Current CF Access session duration defaults to 24h across all gated apps. Hardening to per-class targets is a follow-up task.Rejected as the permanent target (though this is the correct transitional state for Class 2). Post-graduation, stacking TOTP on top of a phishing-resistant passkey satisfies NIST AAL2 twice simultaneously. The security marginal gain is zero; the UX friction is real. Defense-in-depth requires independent layers, not redundant layers of the same type.
The distinction: a passkey is phishing-resistant and origin-scoped; TOTP is phishable (attacker can relay a TOTP code in real time). Adding a weaker second factor on top of a stronger first factor does not improve the overall security posture. If anything, it trains operators to enter codes mechanically, which reduces their TOTP vigilance on surfaces where it matters.
Rejected. Defense-in-depth requires the outer perimeter to remain even when it is relaxed to presence-only. CF Access provides: operator identity allowlist enforcement, session audit logging at the edge, origin guard integration, and the ability to lock a surface instantly (kill-switch) without a Raptor/Heroku deploy. These benefits are independent of MFA. Removing CF Access entirely would lose them.
Rejected. The "strong MFA always everywhere" version of this fails because it conflates surfaces where we control the app auth (and can graduate) with surfaces where we do not (and must compensate). It would permanently impose TOTP on the console even after passkey is GA, which is Alternative A above. The "presence-only everywhere" version fails because it relies on FreeScout and Infisical having equivalent auth quality to a Raxx-built passkey flow, which they do not.
Deferred, not rejected. Hardware key enforcement is the correct long-term posture for credential-bearing operator surfaces. The trigger is a regulatory event or the onboarding of contractors with vault/token-admin access. Requiring hardware keys today would block legitimate operators who rely on platform authenticators (Touch ID, Windows Hello) and is premature given the current operator count (1). This is recorded as Open Question #2 in auth-posture.md §10.