Statamic Two Factor Laravel Package

Technical Evaluation

Architecture fit. mitydigital/statamic-two-factor is a Statamic addon distributed as a Composer package with Laravel package auto-discovery, so it slots into the existing Laravel service-provider/middleware model rather than introducing a parallel framework. It extends Statamic's control-panel authentication (user model columns for the 2FA secret/recovery codes, CP middleware enforcing the challenge, publishable config and migrations). For a Laravel/Statamic stack this is a native fit — no sidecar service, no external identity provider, no separate datastore. The trade-off is coupling: the addon's lifecycle is bound to Statamic major versions, so our upgrade cadence for Statamic effectively gates our 2FA patching cadence.

Integration feasibility. Low-to-moderate. Requires a users-table migration (new columns), a config publish, and an enrollment flow for existing CP users. The recovery-code path adds a support obligation (users who lose their authenticator need an admin-side reset), which is a process design task, not a code task. Staging rollout is straightforward; the main sequencing risk is enforcing 2FA before all CP users have enrolled, which would lock out accounts.

Technical risk. Overall low for this release. Version 2.7.3 is a single-line behavioral fix (PR #41, resolves #40) that changes a state transition from set to remove. Read conservatively, this indicates the addon was previously writing/overwriting a flag where it should have been clearing one — the classic shape of a stale-state defect in an auth challenge flow (e.g., an enrollment or challenge marker lingering in session/cache beyond its intended lifetime). Auth-adjacent state machines are exactly where "set instead of remove" bugs produce either false-positive challenges (annoying) or a bypass window (serious). The patch is small and additive to safety, but it is a behavioral change in an authentication path, so it deserves a regression test pass rather than a blind bump.

Key questions.

1. What exactly is being set vs. removed — a session key, cache entry, user column, or CP publish/broadcast state? This determines blast radius.
2. Does the fix close a bypass (security-positive, prioritize) or merely eliminate a nuisance re-prompt (quality-of-life)?
3. Is there a documented remediation for users who were affected by #40 prior to the patch (e.g., stale flags needing manual clearing)?
4. What is the addon's compatibility matrix for our pinned Statamic and Laravel versions?
5. Does the project have a security disclosure policy / CVE process, or is #40 tracked only as an issue?

Integration Approach

Stack fit. Composer-installable, Laravel auto-discovered, no infrastructure additions. It aligns with our existing CI (PHP lint/static analysis/test) and requires nothing from the frontend build beyond Statamic's CP assets, which the addon ships.

Migration path. (1) Add the package at ^2.7.3 in a feature branch; (2) publish and review config and migrations rather than running them blind — confirm column names and nullability against our users table, especially if we already have SSO or other auth addons; (3) run migrations in staging against a production-shaped snapshot; (4) enroll a pilot group of CP users; (5) enable enforcement for the remainder only after enrollment coverage is confirmed. The patch itself needs no data migration — it is a code-path correction, not a schema change.

Compatibility. Verify against our exact Statamic major and PHP runtime before merging; addons of this type commonly declare a Statamic version constraint that lags new majors. Pin the version explicitly (2.7.3 or ^2.7) rather than floating, so an unreviewed 2.8.0 with breaking config changes cannot land via composer update in CI. Check whether any local overrides or published views touch the code path changed in PR #41 — if we have vendored or overridden files, the fix may not reach our installation.

Sequencing. Treat 2.7.3 as a low-risk patch that can ride the next routine dependency-update train, unless question 2 above resolves to "closes a bypass," in which case it should be expedited as a standalone change with a targeted manual test of the enrollment and challenge flows. Either way, land it before any broader 2FA enforcement rollout so the enrollment state machine is on the corrected code from day one.

Operational Impact

Maintenance. Very low steady-state: one Composer dependency, one config file, one migration. The real maintenance surface is the enrollment/reset runbook, which is ours to own regardless of the package. Budget a recurring line item for reviewing addon releases — this project ships small, frequent patches (2.7.2 → 2.7.3), so an unmonitored dependency will drift.

Support. Expect CP-user tickets of two kinds: lost-device recovery (admin reset + recovery-code regeneration) and re-prompt confusion if any stale-state behavior survives. Brief the service desk on the recovery procedure before enforcement goes live, and make sure at least two admins retain a break-glass path into the CP that does not depend on 2FA.

Scaling. Negligible runtime cost — TOTP verification is a local HMAC computation, no network egress, no external per-auth fee. Volume sensitivity is effectively zero at our CP-user counts. The scaling concern is organizational, not technical: enforcement breadth and recovery workload grow with headcount.

Failure modes. (a) Enrollment lockout — enforcement enabled before coverage; mitigate with staged rollout. (b) Stale challenge/enrollment state — precisely the class of defect #40/2.7.3 addresses; mitigate by testing the abandoned-enrollment path (start setup, navigate away, return) and the partial-challenge path. (c) Clock skew causing valid TOTP codes to be rejected; confirm the configured window and document it. (d) Upstream abandonment or a slow security response from a single-maintainer addon — mitigate by pinning, monitoring, and knowing our fallback (disable the addon and fall back to password + policy controls) if the project stalls.

Ramp-up. Half a day for an engineer familiar with Laravel middleware and Statamic addons to install, configure, and validate in staging. Add review time for the migration against our schema and for the two auth-flow regression tests noted above. No new language or framework competency required.