- Can I install mfakitv4 with composer require into an existing Laravel application?
- No. mfakitv4 is a starter kit, not a consumable library, so it is not designed to be pulled into an existing product with composer require. You clone the repository and treat the resulting application as your own codebase, or you copy the MFA implementation out of it into your project. Either way you own the code afterwards and do not receive upstream patches, so plan for the maintenance yourself.
- Which Laravel and Filament versions does MFAKit v4 support?
- The kit targets Laravel 13.x with a Filament 4.x panel and bundles a TOTP, email OTP, and WhatsApp OTP multi-factor layer. Because it is a template rather than a versioned package, there is no SemVer contract to pin against, so version pinning effectively means pinning a git commit SHA. If your application is on Laravel 12 or Filament 3, expect a multi-sprint extraction effort rather than an afternoon of wiring.
- How do I set up MFAKit v4 on a fresh Laravel install?
- Clone the repository, run composer install, copy the environment file, generate the application key, and run the migrations and seeders as you would for any Laravel skeleton with a Filament panel. The MFA tables for TOTP secrets, OTP challenges, and recovery codes ship with the kit, so migrating is the step that provisions the second-factor schema. Check the README and the migration files for any required queue, cache, or mail configuration before testing the login flow end to end.
- How does TOTP enrollment with QR codes work in this Filament MFA kit?
- Users enroll a TOTP factor from their profile page, which generates a secret and renders a QR code they scan with an authenticator app such as Google Authenticator or 1Password. The kit also supports recovery codes so an account can be regained when the authenticator device is lost. Before relying on it, verify in source that the secret is encrypted at rest, that enrollment requires proving possession of a valid code before activation, and that a previously used code is rejected to block replay.
- Is the MFA challenge enforced for every Filament panel route, or can it be bypassed?
- That is the single most important thing to audit in the source before shipping. The MFA challenge must be a genuine gate: the session state between a successful password check and a successful second factor must not be a fully authenticated session, and it must not be reachable through alternate guards, API routes, or Filament panel guards that skip the middleware. Check whether enforcement lives in middleware, a Filament panel guard, or individual controllers, then test directly by hitting authenticated routes with only the password step completed.
- How are TOTP secrets and one-time codes stored — encrypted or hashed?
- TOTP seeds must be reversible for verification, so they should be encrypted at rest with the application key rather than hashed, while email and WhatsApp OTP codes should be hashed and single use. Read the migrations, casts, and models in the kit to confirm which approach is actually implemented and where the encryption key comes from. Also check the OTP lifecycle: generation entropy, TTL, single-use enforcement, and whether codes can be replayed after a successful verification.
- Does Filament 4 already provide MFA, and what does this kit add on top?
- Filament has progressively absorbed authentication concerns in recent major versions, so it is worth checking whether native MFA already covers your needs before adopting a starter kit. If it does, the value of mfakitv4 is sample code and UI patterns rather than architecture, and the pragmatic decision is to use Filament natively and copy the relevant enrollment screens. The kit's genuine additions are the QR enrollment flow, recovery codes, the profile integration, and the email and WhatsApp OTP channels.
- Is WhatsApp OTP a safe second factor to enable in production?
- Treat WhatsApp OTP as an optional convenience factor and never as the sole second factor. It depends on the Meta Cloud API or a BSP such as Twilio or 360dialog, requires pre-approved authentication-category message templates, costs money per conversation, and adds opt-in compliance obligations plus regional availability gaps. Delivery latency is measured in seconds to minutes, and a provider or template rejection becomes a login outage, so TOTP is the factor to standardize on.
- Are there rate limits on OTP generation and verification, and are recovery codes one-time?
- The kit ships recovery codes, but you must confirm in source that they are hashed and consumed on first use rather than stored in plain text. Check the rate limits on both OTP issuance and verification, including per-identifier and per-IP counters, and where those counters are stored, since a single-node cache behaves differently from Redis in a multi-server deployment. Also verify that the challenge endpoint resists account enumeration through differing responses or timing.
- Is mfakitv4 actively maintained and suitable for production use?
- It is a single-maintainer, low-community project with no security advisory channel, and starter kits typically drift from upstream framework releases and get abandoned at the next major version. MFA is security-critical code, so every guarantee you need — RFC 6238 compliance, secret entropy, clock-drift window, replay rejection, step-up and remember-this-device token design — must be read and tested by you rather than assumed. If you need something consumable and patched upstream, look at Filament's native MFA or a maintained, signed MFA package instead, and validate the future-dated release timestamp and commit history before committing.