Alt Google 2Fa Addon Laravel Package

Technical Evaluation

Architecture fit. This is a Statamic addon sitting on top of Laravel's package system, not a general-purpose Laravel 2FA library. It hooks TOTP (Google Authenticator-compatible) into the Statamic Control Panel login flow. As a TPM the fit question is not "is this good code" but "does our authentication surface belong to Statamic." If editors and admins log in through the CP, this is the cheapest credible way to add a second factor without writing or owning auth code. If our estate authenticates through plain Laravel, Fortify, Breeze, or an IdP/SSO, this addon is architecturally off-target and adopting it would create a second, parallel 2FA mechanism — which is a policy-drift problem, not a security improvement. Scope the decision to Statamic-owned CP authentication and nothing else.

Integration feasibility. Effort is genuinely small: one composer require, one config publish, cache clears, then per-user or enforced enrollment. The v1.1.3 release is a Statamic version-constraint bump only — no migrations, no new config keys, no behavioral changes. That is a positive health signal (the maintainer is tracking upstream) but it also tells us the addon's correctness is coupled to Statamic internals. The TPM-level feasibility question is therefore organizational, not technical: can we get CP users to enroll, and do we have a lockout path before we flip enforcement on?

Technical risk. Four things matter for planning:

• Security-critical surface with an unknown failure posture. Whether enforcement fails closed for unenrolled users is the single highest-stakes unknown. A 2FA addon that can be silently bypassed is worse than none, because it manufactures false assurance in a compliance or audit narrative.
• Vendor and bus-factor risk. Zero GitHub stars, a single contributing handle on the release, no published disclosure policy or test-coverage data in the supplied evidence. Low stars is not disqualifying for a niche CMS addon, but it means we cannot lean on community scrutiny — we must verify the auth path ourselves.
• Upstream coupling. Statamic majors have historically moved auth middleware, user repositories, and session handling. An addon that intercepts that flow can break by simply ceasing to prompt — the worst kind of regression, because it is invisible.
• Constraint drift. A pinned Statamic ceiling on this addon can block a platform-wide CMS security patch. That converts a small dependency into an estate-level release blocker at the least convenient moment.
• Evidence quality. Conclusions here rest on release notes and package identity only. Treat this as a provisional baseline requiring hands-on verification, not a validated assessment.

Key questions.

1. What Statamic/Laravel version ranges does the v1.1.3 constraint admit, and what was the prior floor/ceiling?
2. Does enforcement fail closed — are unenrolled users blocked from the CP when policy mandates 2FA?
3. Are recovery codes supported, how are they stored (hashed, single-use, regenerable), and can users regenerate them self-serve?
4. Is there a break-glass reset (CLI or CP) for locked-out admins, and is it audited?
5. Are TOTP secrets encrypted at rest with APP_KEY, or stored recoverably?
6. Does it coexist with Fortify or other 2FA packages without middleware collision?
7. What is the security disclosure process, and what test coverage exists on the auth path?
8. Who is the named internal owner of this dependency relationship going forward?

Integration Approach

Stack fit. Adopt only where Statamic owns CP login — a Statamic-backed marketing site, docs portal, or lightweight CMS app. Reject for API-first services, customer-facing auth, or any product already standardized on Fortify or SSO. Duplicating 2FA across two mechanisms multiplies support load and makes "is this account protected?" unanswerable without checking two systems.

Migration path. Greenfield is composer require → publish config → clear caches (config:clear, cache:clear, statamic:stache:clear) → configure policy → pilot. Brownfield — replacing a manual or legacy 2FA process — must be additive: enroll users under the addon while the old mechanism stays live, measure coverage, then retire the old path. A hard cutover on a security control without a rollback window is the failure mode to design out.

Compatibility. Compatibility is the substance of v1.1.3, so treat it as a dependency-register event, not a routine patch. Pin the addon to an exact version per environment, record the resolved Statamic/Laravel matrix, and run composer why-not statamic/cms if resolution stalls — a locked older Statamic is usually the culprit, not the addon. Run the upgrade in staging with a real CP login, not a smoke test.

Sequencing.

1. Read the actual constraint diff; confirm the resolved version matrix.
2. Stand up in staging; exercise enroll, verify, successful login, wrong-code, and recovery paths end to end.
3. Explicitly test fail-closed behavior for an unenrolled user under enforcement.
4. Confirm break-glass/CLI reset recovers a locked-out admin.
5. Ship to production for an admin/super-user cohort only; validate for one to two weeks.
6. Widen to all CP users with announced enrollment, then tighten enforcement to mandatory.
7. Only then retire any legacy 2FA process.

Gate each step on evidence from the previous one. Do not compress steps 5–6; that is where most rollouts generate their incident load.

Environment parity. Commit the published config with env-driven values (ALT_2FA_ENFORCE=false in local/testing, true in production) so environments differ without code divergence, and ensure the pipeline runs config:cache after env vars are in place.

Operational Impact

Maintenance. Small code footprint, non-zero attention. The addon must track Statamic releases — this release is evidence it does — so budget a recurring compatibility check each Statamic minor. Assign an explicit owner for the dependency relationship (version tracking, advisory monitoring, upgrade decisions). Leaving that to whoever ran the install is how constraint drift turns into a blocked platform upgrade six months later.

Support. Support burden concentrates almost entirely on enrollment and lockout, not on the package itself. Expect a predictable ticket taxonomy: "new phone, lost codes," "invalid code" (usually clock drift or a code typed outside the window), and "I can't get into the CP." Each needs a documented runbook and a named resolver before enforcement, not after the first locked-out editor. Also budget communication effort — some users will resist enrollment, and a well-explained opt-in phase costs far less than a surprise mandate.

Scaling. Negligible runtime cost. TOTP verification is a local HMAC computation with no third-party call, so there is no external latency, no vendor outage, and no per-seat licensing in the login path. The user population is the CP user base, typically small. The scaling concern is organizational: lockout-adjacent support volume grows roughly linearly with enrolled users, so the runbook and self-serve path matter more at 200 users than at 20.

Failure modes.

• Lockout — lost device plus no working recovery equals an unavailable administrator. Highest frequency, highest impact.
• Fail-open enforcement — 2FA nominally on but functionally bypassable; a silent security regression that surfaces in an audit, not an alert.
• APP_KEY rotation — if secrets are encrypted with the app key, rotation mass-locks-out every enrolled user. Requires a planned migration, never a casual rotation.
• Clock drift — server or container skew produces intermittent "invalid code" reports that are expensive to diagnose and easy to misattribute to the addon.
• Upstream breakage — a Statamic upgrade changes auth internals and the addon stops intercepting; presents as users simply logging in without a prompt.
• Constraint drift — the addon's Statamic ceiling blocks a CMS security patch, forcing a rushed trade-off between an unpatched CMS and an untested addon.
• Secret leakage — TOTP codes, secrets, or recovery codes reaching a log aggregator via custom logging or exception reporting on the login path.

Ramp-up. Technically trivial for a Laravel developer — hours for install and configuration. The real ramp is procedural: enrollment comms, lockout runbook, break-glass procedure, and a staging validation of fail-closed behavior. Estimate a few days to operational readiness. Back up storage/ and the database before rollout, and treat the 2FA fields as migration-sensitive data.

Recommendation for a TPM. Proceed with a conditional adopt, scoped strictly to Statamic CP authentication. Make three verifications the gate to production: fail-closed enforcement, working recovery codes, and a tested break-glass reset. Treat v1.1.3 as a routine compatibility patch requiring no migration — the action item it generates is confirming the new Statamic version ceiling and re-running the staging auth flow. Keep the blast radius small (admin cohort first), name an owner, and document the lockout path before anyone is locked out. If the fail-closed check cannot be evidenced, do not enforce — an opt-in 2FA offering is a defensible interim position; a bypassable mandatory control is not.