Alt Google 2Fa Laravel Package

Technical Evaluation

What shipped in v1.1.3: a single PR (#9, "Bump Statamic versions") by the maintainer. No code changes, no new features, no deprecations, no security advisory. Effectively a composer constraint change on the Statamic dependency for alt-design/Alt-Google-2fa-Addon, an addon that layers Google Authenticator-style TOTP two-factor authentication onto the Statamic control panel.

Architecture fit: Good. As a Statamic addon it registers through an addon service provider and hooks the CP authentication flow rather than the application's domain layer — additive and opt-in, with no expected coupling to business logic. For any Laravel application running Statamic as its CMS, this is a thin, reversible authentication control, which is exactly the kind of thing a TPM should scope as a discrete, low-blast-radius capability.

Integration feasibility: Low effort. Composer install, publish config/assets, configure enforcement policy, enroll users. The integration cost is dominated by rollout and user enrolment, not engineering.

Technical risk: Low in absolute terms, but not zero, and the risk is concentrated in the one thing that changed. The notes say "bump Statamic versions" without stating direction, so the open question is whether v1.1.3 widens the supported Statamic range (benign, enables newer majors) or narrows it by dropping support for older majors (a silent breaking change for pinned installs). Composer fails safe here — a narrowed constraint blocks the upgrade rather than breaking production — but it can also silently strand you on an unsupported addon branch during a Statamic major upgrade. Secondary risks are inherent to the package, not this release: single-maintainer project (vendor concentration), and 2FA being a security-critical surface where "it works" is harder to verify than "it compiles."

Key questions for the maintainer / due diligence:

• Does the v1.1.3 constraint broaden or narrow support, and exactly which Statamic majors and PHP versions are now in range?
• Is there a CI matrix testing the supported Statamic × PHP combinations, or is the bump untested?
• How are TOTP secrets stored — encrypted at rest via Laravel's encrypter, or plaintext in the users table?
• Are recovery/backup codes supported, and is there a documented break-glass or admin reset path for locked-out users?
• Is 2FA opt-in per user or enforceable globally/per-role (super users)?
• Are enrolment, verification failure, and disable events logged for audit?
• Maintenance posture: release cadence, issue responsiveness, license, and bus factor.

Integration Approach

Stack fit: Statamic 3/4/5 on a supported Laravel and PHP 8.x baseline, Composer-based deployment, no meaningful front-end build beyond published assets. Fits standard Laravel Forge/Envoyer/Vapor-style pipelines without special-casing.

Migration path: Treat this as a security control rollout, not a library upgrade. Install, publish, configure, then enable for super users first, followed by editors, then the broader CP population. Run a deliberate optional period before enforcement so enrolment failures surface as support tickets rather than lockouts.

Compatibility: Before merging, run composer why-not alt-design/alt-google-2fa-addon and diff the resolved Statamic version against your pinned constraint in staging. Confirm the addon's constraint does not conflict with your Statamic pin, and confirm your lockfile changes are intentional. If v1.1.3 narrowed support, decide explicitly whether to stay on v1.1.2 or bring the Statamic upgrade forward — do not let it drift.

Sequencing:

1. Stage install and verify CP login + enrolment end-to-end against your exact Statamic version.
2. Confirm secret storage and recovery-code behaviour in the database and UI.
3. Pilot with 2–3 super users; validate clock sync (NTP) on app servers.
4. Document enrolment, recovery, and admin reset; script the help-desk response.
5. Enforce for super users, then roles, then all CP users.
6. Re-evaluate at the next Statamic major; add a dependency-freshness check to your routine.

Operational Impact

Maintenance: Consuming this release is a no-op beyond a lockfile bump. Ongoing cost is low but coupled: the addon's supported Statamic range gates your own CMS major upgrades, so it becomes a recurring item on the upgrade checklist rather than a one-time integration.

Support: Lockouts are the dominant ticket class for any 2FA rollout — lost devices, unenrolled admins, clock skew. You need a documented, tested reset path (artisan command or admin UI) and a break-glass account before enforcement. Single-maintainer ownership means no SLA; plan for the possibility that a future Statamic major is not supported promptly, and keep the removal path (disable 2FA, rely on SSO/IdP) cheap.

Scaling: Negligible. TOTP verification is a single HMAC computation per login; there are no external service calls in the hot path and no per-request overhead for authenticated sessions. Cost scales with CP login volume, which is small by definition.

Failure modes: server clock drift causing rejected codes; unenrolled or newly provisioned admins locked out at first login; unencrypted secret storage turning a read-only DB leak into an account-takeover vector; composer constraint conflict blocking a Statamic security upgrade; addon abandonment leaving you on an EOL Statamic branch.

Ramp-up: Engineering ramp-up is an afternoon. User ramp-up is the real cost — authenticator app installation, recovery-code custody, and a comms plan — and should be budgeted as change management, not as a deploy task.

Verdict: v1.1.3 is a housekeeping release and does not change the decision to adopt or retain the addon. It does raise one question worth an explicit answer before your next Statamic upgrade: which direction did the version bump go, and is that range actually tested?