Filament Two Factor Auth Laravel Package

Product Decisions This Supports

• Build vs. buy for 2FA: This package is a Filament-native two-factor authentication plugin (TOTP + recovery codes) for admin/panel logins. If your roadmap includes "add 2FA to the admin panel," this is a buy/borrow decision that saves weeks of security-sensitive work — 2FA is exactly the kind of feature where shipping your own implementation carries outsized risk for low differentiation.
• Security/compliance roadmap: Admin-panel 2FA is frequently a gate for SOC 2, ISO 27001, or enterprise security questionnaires. This package can turn a blocking compliance item into a one-sprint deliverable, which is a schedule-level decision, not just a technical one.
• v3.0.0 is a maintenance/ownership signal, not a feature release: The release is almost entirely bug fixes and housekeeping, plus one hard breaking change — the namespace moved to Backstage alongside the repository transfer to the backstagephp organization. The product-relevant read: the project has changed hands/stewards and is under active community maintenance. That is a dependency-risk input for build-vs-buy, not an upgrade-for-new-capabilities input.
• Upgrade cost is real but bounded: Because of the namespace change, adoption or upgrade requires a code-level migration (imports, config references, possibly published views/translations). Budget this as a small, scheduled piece of work with a regression pass on the login flow — not a drop-in composer update.
• Quality fixes that map to user-facing pain: The release fixes an infinite redirect loop when the panel path is the base URL, fixes a missing loading state on login, and fixes translation overrides (plus adds German). These are the kinds of defects that generate support tickets and "the login page is broken" escalations — a good argument for upgrading rather than pinning to v2.
• Localization: German translations shipping in core is a small but concrete signal if you operate in DACH markets or have non-English admins; it reduces the "we'll need to fork translations" objection in a procurement/internationalization discussion.

When to Consider This Package

Consider it when:

• You run a Filament panel (admin, internal ops, back office) and 2FA is on your security roadmap or already a compliance requirement.
• You want 2FA scoped to panel users rather than engineering a bespoke auth flow — the integration surface is small and the maintenance burden is externalized.
• You're comfortable pinning and tracking a community package for a security-adjacent capability, and you have a defined upgrade cadence to absorb major-version changes.
• You are either new to the package (adopt v3 directly) or on v2 and willing to schedule the namespace migration — the bug fixes (redirect loop, login loading state, translation overrides) justify the move on their own.

Look elsewhere or proceed with caution when:

• You need enterprise-grade assurance — SLAs, vendor support, a security review, or a documented CVE-response process. The repo just moved organizations; the governance and long-term stewardship story is still forming. Treat bus-factor and continuity as open questions until proven.
• You need 2FA outside Filament (customer-facing app, API, non-panel guards) — this is panel-scoped by design.
• Your team cannot absorb a breaking namespace change on the current cycle. Pinning to v2 is defensible short-term, but you're then carrying known login-flow bugs and stale translations, and the namespace migration cost doesn't shrink by waiting.
• You need hardware keys/WebAuthn, SMS, or push rather than authenticator-app TOTP — verify the method coverage against your actual policy before committing.
• You require vendor accountability — a community-maintained package means you own the risk, the upgrade work, and the incident response, regardless of who maintains upstream.

How to Pitch It (Stakeholders)

For executives: We can close the admin-panel two-factor authentication gap — typically a compliance and security-questionnaire blocker — by adopting an actively maintained open-source plugin instead of building it ourselves. Building 2FA in-house costs engineering weeks and creates a permanent security-surface maintenance obligation for a capability that is not a differentiator. The trade-off is that this is a community package: we take on upgrade work and dependency risk rather than paying a vendor. v3.0.0 signals healthy, ongoing maintenance — bug fixes, new contributors, new translations — alongside a repository transfer to a new steward and a breaking namespace change, which means a small, one-time migration we should schedule deliberately rather than absorb ad hoc. Recommended position: adopt (or upgrade) with a version pin, a scheduled migration ticket, and a login-flow regression test.

For engineering: v3.0.0 is a maintenance release with one breaking change — the namespace is now Backstage following the move to the backstagephp organization — plus fixes for an infinite redirect loop when the panel path is the base URL, a missing loading state on login, and translation overrides, and new German translations. Plan the namespace migration as explicit work (imports, config, published assets), pin the version, and cover the full login + 2FA + recovery-code path with tests before rollout. Also confirm 2FA method coverage and the upgrade path from v2 before committing to a date.