- How do I install and set up filament-2fa in a Laravel Filament panel?
- Install the package with Composer and register the plugin in your Filament panel provider, then publish the config, views and translations if you want to customise them. The integration footprint is small, so most setups are just the Composer require plus panel registration. Before requiring it, confirm the current Composer package name, because v3 moved the project to the Backstage organization and the vendor name may have changed alongside the PHP namespace.
- Does filament-2fa support Laravel 11 and Filament v3 or v4?
- The package targets session-guarded Filament admin panels on Laravel 10, 11 and 12 with Filament v3, which is the safe baseline to plan around. Filament v4 support should be confirmed against the current release notes before you commit to it. After bumping the version, run composer why-not to surface any Laravel, Filament or PHP constraint conflicts early.
- What changed in filament-2fa v3.0.0 and how do I migrate from v2?
- v3.0.0 is a major release driven mainly by the repository transfer to the Backstage organization, and the breaking change is the PHP namespace moving to Backstage. The release notes describe only the namespace change, but the Composer package or vendor name may also have moved, so verify that on Packagist first. The edit itself is mechanically simple, yet it touches every reference: application code, published views and config, custom subclasses or overrides, and cached artifacts.
- Do I need to republish config, views and translations after upgrading to v3?
- Yes, treat republishing as part of the upgrade. Any published config, Blade views or translation files that reference the old namespace need to be refreshed or updated by hand, otherwise you risk partially applied changes. After republishing, clear the config, view, route and autoload caches so no stale artifacts survive the deploy.
- Are existing 2FA enrollments and recovery codes preserved when upgrading?
- The v3 release notes state only the namespace change, and no data migration is mentioned, so existing TOTP secrets and recovery codes should carry over untouched. That said, this is an auth-critical path, so validate it rather than assume it. Verify in a production-like environment with a real 2FA login against a test admin account before releasing.
- How do I enforce two-factor authentication for all admin users?
- The package ships middleware to enforce 2FA for admin access plus a profile page where users enable and manage it. Register the plugin and middleware in the relevant panel so unenrolled users are pushed into setup instead of reaching protected resources. Include a panel mounted at the base URL in your regression tests, since a redirect-loop fix for that routing edge case is part of the release.
- Does filament-2fa work with authenticator apps and recovery codes?
- Users enable TOTP by scanning a QR code with an authenticator app such as Google Authenticator or 1Password, and the package also issues recovery codes for when the device is unavailable. Test the full lifecycle in staging: enrollment, challenge at login, recovery code use, disable and reset, remember-device behaviour and translation overrides. Also check the login button loading state, which is easy to break with view overrides.
- Is filament-2fa a replacement for Laravel Fortify's two-factor authentication?
- The package is designed to integrate Laravel Fortify easily into Filament apps, so it builds on Fortify's two-factor features rather than replacing your whole auth stack. If you already run Fortify 2FA directly, review the overlap before adding the plugin to avoid duplicate flows. It fits Laravel monoliths and modular monoliths with session-based admin auth, and is not relevant for API-only or headless services.
- What are the production risks of adding 2FA to a Filament admin panel?
- This sits on an auth-critical path, so failure modes range from boot-time class-not-found errors to login lockout or a silent 2FA bypass. The v3 namespace move is easy to apply only partially in repositories with stale published files, which is where most incidents come from. Test enroll, challenge, recovery codes, disable and reset, remember-device and panel registration, then release with an explicit rollback plan that re-pins v2.1.0 and clears caches.
- Is filament-2fa actively maintained, and what should I check after the repo transfer?
- Steady-state effort is low: it is a small plugin with recent bug fixes and translations, and the migration is a single isolated change rather than an ongoing burden. The organization transfer introduces governance questions, so check whether the old vendor and package name are formally deprecated on Packagist, where security advisories will be published, and whether the redirect-loop fix was backported to v2.1.x. If you need to stay on the old line temporarily, confirm how long it will receive security fixes before pinning it in production.