Statamic Two Factor Laravel Package

Product Decisions This Supports

• Security roadmap prioritization: This package delivers TOTP-based two-factor authentication as a drop-in Statamic addon, letting you check the "MFA available" box on security/compliance questionnaires (SOC 2, ISO 27001 vendor reviews, enterprise procurement) without building or maintaining crypto, enrollment, and recovery-code flows in-house.
• Build vs. buy: Strong buy signal. Enrollment UX, QR provisioning, recovery codes, and CP integration are well-trodden but deceptively expensive to get right; a maintained addon at a 2.7.x maturity level shifts engineering spend to product differentiation instead of auth plumbing.
• Use cases it unblocks: Client-facing CMS deployments where editors hold publish rights; agency/partner portals; any Statamic install behind SSO-adjacent procurement requirements where full IdP integration is overkill.
• Release-specific signal (2.7.3): The change swaps a "set" call for "remove" (issue #40) — a correctness fix in how a state value is cleared, most plausibly session/cookie or enrollment-state handling. Read it as maintenance hygiene, not scope change: the maintainer is responsive to bug reports and shipping narrow patches. That reliability supports continued adoption but does not change roadmap sequencing.
• Patch cadence as a health metric: A 2.7.3 release within the 2.7.x line indicates active maintenance. Track version cadence as a lightweight dependency-risk indicator for the quarterly dependency review.

When to Consider This Package

Adopt when:

• You run Statamic (v4/v5-era) and need MFA for Control Panel users without standing up an external IdP.
• Your threat model is credential-stuffing and phished editor passwords — the common real-world CMS risk — rather than full device-trust or conditional-access policy.
• You want functionality your own team can uninstall or replace without deep coupling, i.e., the addon is a leaf dependency.
• A patch-level release like 2.7.3 is acceptable to you without a re-review cycle — this one carries no migration steps, no config signature changes, and no deprecations.

Look elsewhere when:

• You require WebAuthn/passkeys, hardware keys, or push-based MFA — TOTP-only coverage won't satisfy that requirement.
• You need organization-wide enforcement with IdP policy (Okta, Entra ID, Google Workspace) — SSO is the correct answer, and bolting MFA onto local accounts creates a second, weaker identity silo.
• Your user base is non-technical or high-churn — TOTP enrollment friction and recovery-code support generate real helpdesk load; weigh that against the licensing cost.
• You need a formal security attestation (pen test report, published CVE process, SLA) from the vendor. Assess support terms and the bus factor of a single-maintainer addon before routing privileged access through it.
• You're on an unsupported Statamic major — verify compatibility before committing.

Action for 2.7.3: no upgrade planning required. Take it in the normal patch window; confirm the "remove vs. set" behavior against your enrollment and recovery flows in staging, since a state-clearing change can surface as a re-prompt or a stale-enrollment edge case rather than a hard failure.

How to Pitch It (Stakeholders)

To executives: We can close a recurring security gap — privileged CMS logins protected only by a password — using a small, actively maintained addon rather than a custom build. A 2.7.x maintenance release landed this cycle with a narrow bug fix and no breaking changes, which is the profile we want from a dependency: low ceremony, low risk, steady upkeep. Decision needed: approve adoption and a one-time configuration/rollout effort; no ongoing engineering headcount.

To engineering: This is Statamic-native TOTP MFA for the Control Panel — enrollment, verification, and recovery handled for us. Version 2.7.3 is a patch that replaces a "set" with a "remove" to resolve issue #40; treat it as a routine bump with no API or config migration. Before rollout: verify compatibility with our Statamic version, decide enforcement scope (all CP users vs. privileged roles only), document recovery-code handling, and confirm our backup/break-glass path so a lost device can't lock out an administrator. If we later need passkeys or org-wide conditional access, we graduate to SSO — this addon shouldn't be extended into that role.