Totp Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the 2FA enrollment experience. The actual decision isn't "do we adopt TOTP" — it's "do we spend 1–3 sprints building QR-code, secret-display, code-verification, and backup-code screens, or adopt a thin pre-built UI layer?" This package is a template-and-controller starter kit over scheb/2fa-bundle, so it shifts effort from UI construction to integration review. Note the decision fork: the engine (Scheb) is mature and widely depended upon; the UI layer (this package) is unproven. You can adopt Scheb on its own merits and treat this UI as optional, replaceable scaffolding.
• Scoping the MFA roadmap and separating concerns. This package gives you a clean line between authentication mechanics and enrollment UX. That matters for prioritization: you can commit to TOTP as a capability without committing to this specific presentation layer, and you can defer passkeys/WebAuthn (which this package does not address) as a distinct roadmap item.
• Compliance and sales-enablement sequencing. If enterprise security questionnaires, SOC 2 readiness, or B2B procurement checklists are blocking deals, TOTP enrollment UX is a concrete, low-cost roadmap item to unblock them. Conversely, if the real gap is passkeys or step-up auth, this package is not the answer and shouldn't be scoped as if it were.
• Prioritizing internal vs. external surfaces. Best fit is admin consoles, back-office tools, and B2B tenant admin accounts — surfaces where functional correctness beats polish and where you control the user population. Not the right starting point for consumer-facing flows requiring recovery UX at scale or multi-device management.
• Framing the dependency-policy decision. With 3 stars, 0 dependents, and a single maintainer, the honest framing is "reference implementation / vendored starting point," not "third-party dependency we rely on for security-critical UX." This package is a candidate for fork-and-own, not vendor-and-depend.
• Framework direction as a gating decision. The repo is a Symfony bundle despite the "Laravel/PHP" indexing frame. The first PM-level call is whether a Symfony service actually exists in the estate. If it's Laravel-first, the recommendation flips to Fortify or pragmarx/google2fa and this package becomes a design reference only.

When to Consider This Package

Consider it when:

• You are on Symfony and already using or committed to scheb/2fa-bundle with Twig available. This is the natural, low-ceremony fit — near drop-in only if Scheb's 2FA core is already wired into a firewall.
• You need a working TOTP setup screen fast for an internal or B2B-facing app, and can afford a security review plus light customization. Effort is roughly hours to a day on a Symfony target.
• Your team is comfortable forking under MIT, pinning a commit, and owning the code — i.e., you're evaluating it as a code sample, not as a maintained dependency.
• You have a bounded user base where backup-code and re-enrollment flows can be simple, and where the parent bundle's default templates don't already satisfy the requirement (verify this first — the wrapper may be redundant).

Look elsewhere when:

• You're on Laravel. The idiomatic answer is laravel/fortify (ships TOTP and recovery codes), or a small Blade UI over pragmarx/google2fa with bacon/bacon-qr-code. The bundle's Symfony service wiring and Twig templates won't port; adopting it in Laravel is a rewrite, not an install.
• You need passkeys/WebAuthn, SMS fallback orchestration, or step-up auth — web-auth/webauthn-lib or Symfony UX are the relevant paths.
• You require an actively maintained dependency with a CVE response process and an SLA. Zero dependents is not evidence of production use, which means security-critical paths (CSRF, secret leakage into logs, backup-code generation and hashing, rate limiting on verification) have not been battle-tested by a community.
• You need recovery UX at scale, multi-device management, or admin-side reset/audit tooling — those are custom work regardless of package choice.

How to Pitch It (Stakeholders)

To executives: This is a small open-source UI layer that can shortcut the TOTP enrollment screens required by enterprise security reviews — potentially saving a sprint or two on a checkbox that unblocks deals. It is not a validated dependency: it's a single-maintainer project with essentially zero adoption, and it is a Symfony component despite the Laravel/PHP framing. The recommendation is to treat it as a reference implementation we fork and own, not as a vendor we rely on. Budget a security review either way; the 2FA engine underneath (Scheb) is the mature part and carries most of the risk reduction. If our estate is Laravel-first, the equivalent shortcut is Fortify, and this package becomes a UX reference rather than a dependency.

To engineering: It's a thin Symfony UI over scheb/2fa-bundle — Twig templates, setup controllers, QR rendering, and backup-code display, with no security guarantees of its own. Expect to vendor/fork under MIT, pin a commit, and review the enrollment and verification paths for CSRF, secret exposure in logs/telemetry, secure backup-code storage, and rate limiting. Sequencing matters: prove end-to-end TOTP on Scheb's default templates first, then layer this UI and compare — if the defaults suffice, stop and don't take the dependency. Roll out behind a feature flag with the parent bundle's default templates as a documented kill switch. On Laravel, this does not apply — Fortify covers the same ground with a maintained upstream, and total integration cost should be compared before choosing.