Twofactorauth Laravel Package

Product Decisions This Supports

• Build vs. buy for MFA: TOTP is a solved, commoditized primitive. The default PM decision should be adopt — writing your own TOTP verifier (base32 decoding, HMAC-SHA1, time-window drift, replay checks) is pure downside risk. This package is the "buy" answer with a zero-dollar price tag.
• Roadmap: unblocking enterprise deals. 2FA is a named control in SOC 2 (CC6), ISO 27001 (A.8.5), PCI DSS (8.4), HIPAA safeguards, and virtually every vendor security questionnaire and cyber-insurance application. Shipping it converts "security review failed" into "security review passed."
• Feature scoping — parity, not differentiation. The low opportunity score (0.4) is the signal: nobody wins a deal because of TOTP. Position it as table-stakes hygiene, not a launch-worthy feature. Don't spend roadmap narrative capital on it; spend compliance capital.
• Use cases it unlocks: admin/privileged account protection, step-up authentication for sensitive actions (payout changes, API key creation, data export, permission grants), 2FA on customer-facing B2B logins, and internal-tool hardening.
• Effort framing for planning: library integration is days; the product around it (enrollment UX, recovery codes, reset/support flow, rate limiting, audit events) is weeks. Budget the second number, not the first.
• Decisions it explicitly does not support: passkeys/WebAuthn, push, SMS, risk-based/adaptive MFA, device trust, or passwordless. If the strategic conversation is "passwordless roadmap," this is the wrong artifact — flag it and route to a different evaluation.

When to Consider This Package

Adopt when:

• You need standards-compliant RFC 6238 TOTP that works with Google Authenticator, 1Password, Authy, and Microsoft Authenticator, and nothing more.
• You're on PHP/Laravel, MIT licensing is acceptable, and you're comfortable owning everything above the crypto: storage, encryption, UX, policy.
• You want a small, dependency-light verifier rather than a heavyweight auth platform, and you want to keep the option to swap providers later.
• You need HOTP as a fallback or QR provisioning URIs for enrollment (pair with bacon/bacon-qr-code for rendering).

Look elsewhere when:

• You want batteries included. Laravel Fortify ships 2FA plus recovery codes, confirmation, and Blade scaffolding. pragmarx/google2fa-laravel gives you a service provider and facade. This library gives you neither — you'll write the glue.
• You need passkeys/WebAuthn. Use web-auth/webauthn-lib or laravel/passkeys; TOTP libraries cannot be extended into this.
• You need adaptive/risk-based MFA, device trust, admin override, SSO/SCIM, or audit reporting — that's an identity vendor decision (Auth0, WorkOS, Okta, Clerk), not a library decision.
• Procurement requires an SLA, indemnification, or support contract. MIT gives you none of that; the supply-chain risk sits with you.
• You're not prepared to own the gaps. This library has no rate limiting, no replay protection, no account lockout, no recovery codes, no UI, no migrations, no Laravel service provider. Realistically plan for 4–8× the library's surface area in your own code.

How to Pitch It (Stakeholders)

For executives: "Two-factor authentication is currently a blocker in enterprise security reviews. We can close it in roughly [X] engineer-days using a maintained, MIT-licensed library — no license cost, no vendor contract, no lock-in. It's a compliance and deal-velocity play, not a differentiator: expect parity with competitors, not a selling point. The meaningful cost isn't the cryptography, it's the recovery and support experience, and that's where the budget should go."

For engineering: "Small, framework-agnostic TOTP/HOTP verifier — a good fit as a swappable component. We own the Laravel service provider, migration, encrypted secret storage, rate limiting, replay guard, recovery codes, and QR rendering. One to two days gets admin 2FA working; one to two weeks gets it supportable in production. If we'd rather not own that surface, Laravel Fortify gives us 2FA plus recovery codes pre-assembled, and an identity vendor gives us passkeys and policy but adds cost and lock-in. Recommendation: adopt behind an interface we control, so a later move to WebAuthn is an implementation swap, not a migration."

Risks to state up front: no vendor SLA under MIT; maintenance depends on a small contributor base (recent release cadence is a positive signal, not a guarantee); scope ends at the crypto primitive. And the recurring product risk: users lose phones. Decide the recovery policy — support-mediated reset vs. backup codes — before launch, because it determines your ongoing support cost more than the library choice does.