Two Factor Authentication Laravel Package

Product Decisions This Supports

• MFA as a roadmap gate, not a feature. This package supplies the enforcement policy layer — who must enroll, when a challenge is required, how step-up auth is triggered for sensitive actions — plus the recovery-code primitives (generate, hash, single-use consume). That is precisely the decision-heavy part of an MFA build, and it maps directly to questions like "do we force enrollment at signup, at first admin action, or at contract signature?"
• Build vs. buy, scoped honestly. RFC 6238 TOTP is a solved, ~200-line problem; the real cost is policy (cohort targeting, grace periods, lockout escape hatches, audit trail) and recovery UX. A package that ships policy + primitives but no UI means you buy the boring correctness and own the product surface — a favorable split for a PM who wants control over enrollment friction.
• Compliance and enterprise-sales unblocking. SOC 2, ISO 27001, PCI DSS 8.4.1, and most enterprise security questionnaires require MFA for administrative and PII-touching access. This is a checkbox that closes deals and shortens security reviews; sequencing it before SSO/SCIM is usually the higher-leverage order.
• Support-cost reduction via recovery codes. One-time recovery codes are the difference between "user lost their phone, support resets the account" and "user self-serves." The ticket-volume delta is measurable and is often the fastest ROI in an MFA program.
• Step-up authentication as a product primitive. Once policy is a first-class object, you can gate withdrawals, API key creation, data export, or role changes behind a re-challenge without redesigning login — a cheap way to raise trust on high-value flows.
• Metrics to instrument from day one: enrollment rate by cohort, challenge success rate, median time-to-enroll, recovery-code issuance and consumption rate, lockout tickets per 1k MAU.

When to Consider This Package

Consider it when:

• You are already inside the Liberu module ecosystem and want consistency with its modular conventions rather than a standalone auth stack.
• You want a policy object (enforcement rules, grace periods, cohort targeting) rather than an end-to-end MFA feature with views, QR provisioning, and middleware opinions.
• You are building step-up authentication and want the recovery-code lifecycle handled so your team doesn't hand-roll hashing, single-use semantics, and constant-time comparison.
• You treat dependencies as reference implementations to fork or wrap — MIT license makes that clean, and the surface is small enough to audit in an afternoon.
• You have in-house PHP capacity to own schema, migrations, UI, and tests.

Look elsewhere when:

• You need social proof or vendor assurance. Zero stars and zero dependents means no production validation, no community bug-finding, and no meaningful signal on maintenance continuity. For an auth path, that is a real risk, not a cosmetic one.
• You need a batteries-included flow: QR provisioning, device trust, remember-this-device, backup email fallback. Laravel Fortify, Laragear TwoFactor, or pragmarx/google2fa cover that ground with far larger user bases.
• You need passkeys/WebAuthn. This is TOTP-shaped; don't stretch it. Plan a separate track.
• You require an SLA, security disclosure process, or CVE history you can point auditors at.
• Your team cannot absorb a fork. Adopting a single-maintainer module without the capacity to own it is a liability disguised as a shortcut.

How to Pitch It (Stakeholders)

To executives: MFA is now a procurement gate — enterprise buyers and security reviewers ask for it by name, and its absence stalls deals. This package gives us the enforcement policy and recovery-code mechanics under MIT, so the spend is mostly our own integration effort rather than license or vendor lock-in. Two caveats worth stating plainly: it has no community traction, so we should treat it as a reference implementation we fork and own rather than a dependency we rely on; and it deliberately excludes the user-facing enrollment experience, which is where the real cost sits. Recommendation: fund a two-week spike, not a program. Success looks like a working admin-cohort enforcement path with measured enrollment and lockout-ticket baselines, and a decision on build-vs-fork at the end.

To engineering: Small, legible surface — TOTP enforcement policy plus one-time recovery-code primitives. It does not own your schema, your middleware, your QR/provisioning UI, or your device-trust story; you do. That's the trade: you inherit policy semantics and recovery-code lifecycle correctness (hashing at rest, single-use consumption, constant-time comparison) and you keep control of everything user-visible. Expect to vendor the code, add tests around clock skew and replay, and document the fork. Do not adopt it as an unpinned transitive dependency.

Ask: one engineer, two weeks, time-boxed; deliver a go/no-go on fork-and-own versus Laravel Fortify, with the enrollment UX and recovery flow prototyped enough to estimate the remainder.