Alt Google 2Fa Addon Laravel Package

Product Decisions This Supports

• Security/roadmap commitment: whether 2FA on admin surfaces is a "someday" backlog item or a shippable feature this quarter. This addon turns a multi-sprint build into a config-and-rollout exercise, which makes the decision about policy and rollout, not engineering capacity.
• Build vs. buy: buy, in the narrow case where Statamic owns the control-panel login. The build side is deceptively expensive — TOTP generation, QR enrolment, recovery codes, enforcement middleware, lockout tooling, and the ongoing maintenance. A composer package is the cheap path if the fit is exact.
• Sales/compliance unblocking: if enterprise or public-sector buyers ask "is admin access MFA-protected?" in security questionnaires, this is the fastest route to a "yes" on a Statamic site. Quantify this as deal-unblocking value, not infrastructure cost.
• Risk scope decision: this is CP/admin-side 2FA only. It does not solve customer-facing MFA or API auth. Treat it as an internal-access control in the roadmap, not a product-level security feature — conflating the two creates a false sense of coverage that surfaces later in audits.
• Scope triage for adjacent auth work: adopting this explicitly deprioritizes building 2FA into the product itself for this site, and takes Fortify/Breeze integration off the table for that surface. Duplicating 2FA mechanisms across the estate creates policy drift and doubled support load.
• Vendor-management overhead: a 0-star, single-maintainer package on a security-critical path means adding a dependency-ownership line item (version tracking, advisory monitoring) to someone's roadmap, not just a one-time install.

When to Consider This Package

Adopt when all of the following hold:

• Statamic is the authentication surface. Editors and admins log in through the Control Panel. If auth lives in plain Laravel, Fortify, Breeze, or a separate IdP, this is the wrong primitive.
• The user base is internal and small. A CP user list of tens, not thousands. The dominant operational cost is lockout support, which scales linearly with enrolled users.
• A documented runbook can exist before rollout. Recovery codes, a break-glass CLI reset, and a named owner. If nobody will own the lockout queue, don't adopt.
• You can verify fail-closed enforcement in staging. Not from the README — from the code and a real login flow. Users without an enrolled secret must be blocked when policy is mandatory.
• You can commit to tracking Statamic upgrades. The most likely failure mode isn't a bug, it's a stale Statamic constraint that blocks a platform security patch across the whole CMS estate.

Look elsewhere when:

• Non-Statamic Laravel apps are in scope — pick one 2FA approach for the estate rather than three.
• You already have an SSO/IdP (Okta, Entra, Google Workspace) that can enforce MFA at the identity layer. That's strictly better than per-app TOTP: central policy, central deprovisioning, no per-site lockout runbook.
• You need customer-facing MFA, SMS/WebAuthn/passkeys, or compliance-grade audit logging of authentication events.
• Security procurement requires a vendor with a disclosure policy, published test coverage, or SLAs. With one contributing handle and no visible security process, this fails vendor review regardless of code quality. In that case, budget the build or go IdP.
• You can't accept unverified security semantics. If enforcement, secret storage, and recovery-code handling can't be confirmed in a timeboxed technical review, the correct PM call is to not ship it on a security control.

How to Pitch It (Stakeholders)

For executives: We have a decision to make about whether admin logins to our Statamic site are protected by multi-factor authentication. Right now they aren't. The options are a cheap package, an expensive internal build, or an identity-provider migration. This package is the cheap option — it adds authenticator-app 2FA to the admin panel with a config change and a rollout plan, not a project. It's low cost and reversible, but it comes from a small vendor and touches the login path, so it needs a short technical review and a documented recovery process before we turn it on. Recommendation: pilot with admins, verify recovery works, then enforce — or, if we're already paying for an identity provider, route through that instead and skip this entirely.

For engineering: This is a Statamic addon that layers TOTP onto the existing CP auth flow — additive, not a replacement. Install is a composer require plus a config publish; most behaviour lives in config, so commit it with env-driven enforcement flags. The v1.1.3 release is a Statamic version-constraint bump only, no migrations or API changes — but verify what the new constraint actually resolves to. Treat the login path as security-critical: confirm it fails closed for unenrolled users under enforcement, confirm how secrets are stored at rest, confirm recovery codes are hashed and single-use, and confirm there's a break-glass reset. Freeze the clock in tests for deterministic TOTP assertions. Two hard rules: never rotate APP_KEY on a site with enrolled users without a migration plan, and never log codes or secrets. Staging must exercise enrol, verify, failed-code, recovery, and lockout before production sees it.

The ask: a timeboxed technical review (fail-closed enforcement, secret storage, recovery path, version matrix), a staging pass of the full auth flow, and one named owner for the dependency — before we set enforcement to mandatory.