Skip to content

Multi-Factor Authentication (MFA)

Statement

ClaimGuard's MFA posture today is asymmetric:

  • Cloud / infrastructure access is fully MFA-gated through Google Workspace. Every privileged action against the GCP project — gcloud invocations, console sign-in, Secret Manager access via human identity, IAP-SSH to the VM — runs under a Workspace identity that Workspace's policy requires MFA on.
  • Application access does not have MFA. Customer staff authenticate with email + password and receive a JWT; there is no TOTP, WebAuthn, or push-based second factor in the application today.

Closing the application-side MFA gap is a roadmap item (TOTP first, WebAuthn next) and is the reason this control sits at partial.

Implementation

Cloud-side MFA

  • Workspace policy: mandatory MFA at the Workspace organizational-unit level for every member of dtectvision.ai.
  • Coverage: Google Cloud Console, gcloud CLI, IAP-SSH (the Workspace identity authorizes the IAP tunnel). See Privileged access.
  • Methods: the Workspace policy permits security keys (FIDO2), Google prompt, and TOTP. Phone-based SMS is permissible for fallback but not preferred.
  • No personal accounts in the owner set as of post-A1.4-step1 cleanup. The one remaining personal-account principal (idonithid@gmail.com) is a developer, not an owner, and is scheduled for re-binding to a Workspace identity. See Identity provider.

Application-side MFA — what's not in place

The application:

  • Does not present a second-factor enrollment screen at first login.
  • Does not have a TOTP secret column on the users table.
  • Does not integrate WebAuthn.
  • Does not require step-up authentication on sensitive actions (password change, role change, API-key issuance).

The defense for credential compromise on the application side today is a combination of bcrypt-12 storage, IP rate-limiting on the login endpoint, and the absence of a public-facing TLS path until plan step A1.3 lands (mitigated by the product not yet being in customer hands). This is sufficient for the current pre-launch state but is not the long-term answer.

Status

partial — verified 2026-04-29.

What's in place:

  • Workspace-policy-enforced MFA across every cloud-administrative surface.
  • IAP-SSH gating that re-uses the Workspace MFA posture.
  • A small enough cloud-administrator set that an exception (e.g., a lost device) is detected and remediated by the founder pair directly.

Known gaps

  • No application-side MFA of any kind.
  • No step-up authentication on sensitive actions.
  • No documented Workspace MFA-method policy — Workspace's defaults apply but a written organizational-policy doc has not been authored.
  • No MFA-bypass alerting — a workspace-level event for "MFA bypass code generated" is not currently surfaced into a paging channel.

Roadmap

  • TOTP for application logins (the lightest implementation that closes the largest gap). Per-user enrollment with backup codes; enforce on roles ADMIN and SUPER_ADMIN first; opt-in for REVIEWER / EXEC_VIEWER until enforced fleet-wide.
  • WebAuthn / passkeys as a fast-follow for users who prefer passwordless or hardware-key authentication.
  • Step-up authentication on the password-change, role-change, and API-key-creation endpoints.
  • Workspace MFA-method policy doc committing to security-key-or-TOTP only (no SMS) for owner-class principals.
  • MFA-bypass alerting wired into the Cloud Logging audit-log alerting pipeline once that pipeline exists (cross-listed on Incident response).