Mfakitv4 Laravel Package

Technical Evaluation

What this actually is. mfakitv4 is a starter kit, not a consumable library. It ships a Laravel 13.x application skeleton with a Filament 4.x panel and an MFA layer (TOTP, Email OTP, WhatsApp OTP). That distinction drives every downstream conclusion: you cannot composer require it into an existing product, and you do not receive upstream patches. You clone it or you extract from it, and thereafter you own the code.

Architecture fit.

• Strong fit only at the intersection of three conditions: greenfield (or willing-to-rewrite auth), Laravel 13, and Filament 4 as the admin/end-user panel. Missing any one of these converts an afternoon into a multi-sprint extraction.
• The MFA layer is the only genuinely reusable asset. The rest is scaffolding you would otherwise get from laravel new plus a Filament panel installer.
• Filament 4 has been progressively absorbing authentication concerns (panel auth, and MFA in recent majors). A key risk is that this kit is a thin wrapper over first-party Filament capabilities — in which case the value is sample code, not architecture, and the correct decision is to use Filament natively and copy patterns.

Security surface — where the real diligence sits. MFA code is security-critical and this is a 10-star, single-maintainer project. None of the following can be assumed; each must be read in source:

• TOTP: RFC 6238 compliance, secret length/entropy, encrypted-at-rest storage of seeds, clock-drift window, replay rejection of a previously used code.
• OTP lifecycle: generation entropy, hashing at rest, TTL, single-use enforcement, per-identifier and per-IP rate limits, enumeration resistance on the challenge endpoint.
• Enrollment/rotation: proving possession before activation, preventing silent factor replacement (a classic account-takeover vector), recovery-code generation, hashing, and one-time consumption.
• Login flow integrity: the MFA challenge must be a genuine gate — session state between password success and MFA success must not be a fully authenticated session, must not be reachable by alternate guards, API routes, or Filament panel guards that bypass the middleware.
• Step-up auth and "remember this device" token design.

Factor-specific risk.

• TOTP — lowest risk, no vendor, no marginal cost. This is the factor to standardize on.
• Email OTP — acceptable as fallback; carries deliverability dependency and is phishable. Ties your login path to your transactional email provider's reputation.
• WhatsApp OTP — highest risk. Requires Meta Cloud API or a BSP (Twilio, 360dialog), pre-approved authentication-category message templates, per-conversation cost, opt-in compliance obligations, regional availability gaps, and delivery latency measured in seconds-to-minutes. Provider or template rejection is a login outage. Treat WhatsApp as an optional convenience factor, never the sole second factor.

Technical risk summary. Bus factor 1; no security advisory channel; no SemVer contract to pin against (it is a template, so version pinning means git SHA); starter kits drift from upstream framework releases and are typically abandoned at the next major; low community means vulnerabilities are found by you, not reported to you. The future-dated 2026-09-23 release timestamp warrants a quick provenance check (tag signing, commit history continuity) before anything else.

Key questions to answer before committing.

1. Does Filament 4 provide this MFA natively, and if so what does this kit add beyond wiring and UI?
2. Is the MFA challenge enforced in middleware, a Filament panel guard, or per-controller? Are there paths that reach authenticated routes pre-challenge?
3. How are TOTP seeds and OTP codes stored — encryption scheme, key management, hashing algorithm?
4. What are the rate limits on OTP issuance and verification, and where is the counter stored (single-node cache vs. Redis)?
5. Are recovery codes implemented? Hashed? One-time?
6. Which WhatsApp provider is integrated, and is delivery queued or synchronous in the login request?
7. Test coverage on the auth flow specifically — are there feature tests asserting bypass resistance?
8. Is there any commit activity in the last 90 days, and does the maintainer respond to issues?

Integration Approach

Stack fit checklist. PHP 8.3/8.4, Laravel 13, Filament 4, Livewire, Tailwind, MySQL/Postgres, Redis for rate-limit and session state, a queue worker (mandatory — OTP dispatch must not be synchronous), and outbound HTTPS to your email and WhatsApp providers.

Choose one of three paths, explicitly.

Path A — Adopt as baseline (greenfield only). Clone, strip demo data, rebrand, pin the commit SHA in your repo history, then treat it as your own codebase from commit zero. Fastest to a working MFA-enabled panel; you inherit whatever security posture the kit has.

Path B — Extract (existing application). Lift only the MFA domain: migrations for factor/recovery-code tables, the TOTP/OTP service classes, the Filament challenge and enrollment pages, and the middleware. Re-implement the wiring against your existing User model, guard configuration, and design system. This is the common case and it is materially more work than Path A — budget for it.

Path C — Reference only. Read the implementation, adopt Filament's native MFA (if adequate), and use this repo as a pattern library. Lowest dependency risk, highest engineering cost, best long-term position for a security-sensitive surface.

Migration path and sequencing.

1. Spike (2–3 days). Clone, run locally, execute the full enrollment → challenge → verify → recovery loop for all three factors. Confirm the stack versions resolve together.
2. Security review (1 sprint). Read the auth flow line by line against the checklist above. Write bypass tests before writing product code. This is the gate — do not proceed on a verbal "looks fine."
3. Decide factor policy. TOTP required-capable, Email as fallback, WhatsApp optional and feature-flagged. Never WhatsApp-only.
4. Extract or adopt (1–2 sprints). Include DB migrations, backfill plan for existing users (all start unenrolled), and a mfa_enforced_at column to drive a grace period.
5. Pilot behind a flag. Enable for internal users and a small tenant cohort. Instrument enrollment rate, challenge success rate, OTP latency, and support-ticket volume.
6. Enforce with a grace period. Communicate a fixed deadline; provide recovery-code download at enrollment; staff the helpdesk for identity-verification-based resets.
7. Retire the fork's demo artifacts and record an internal ownership note — this code has no upstream.

Compatibility notes. Laravel 13 and Filament 4 are recent majors; third-party package compatibility across the ecosystem will still be settling. Pin exact versions in composer.lock, and re-verify the whole dependency graph at each framework minor. Expect the annual Laravel major and periodic Filament majors to require manual upgrade work on your fork indefinitely.

Operational Impact

Maintenance. You inherit 100% of the code. There is no upgrade path, no patch stream, no deprecation notice — only your own diffing against future Laravel and Filament releases. Budget a recurring 3–5 engineer-days per framework major plus a security review cadence (at minimum annually, and on any PHP/Laravel security release touching auth or sessions). Compare this against the ongoing cost of a maintained MFA dependency; for most teams the fork is more expensive past year two, and is justified mainly by control over a security-critical path.

Support. Single maintainer, 10 stars, no SLA, no documented security disclosure process. For MFA specifically this is the weakest dimension: you cannot rely on upstream for a CVE response. Mitigation is ownership — name an internal code owner, add the MFA module to your vulnerability-management scope, and subscribe to Laravel/PHP security feeds yourself.

Scaling.

• TOTP is effectively free and stateless — it should carry the majority of volume.
• Email OTP scales with your ESP; cost is negligible but reputation management is real (dedicated subdomain, bounce handling).
• WhatsApp scales with money and provider quotas: per-conversation pricing, template throughput limits, and business-account quality-rating risk if users mark messages as spam. Model this — at 10k monthly active logins with 20% WhatsApp adoption, you are paying per login event indefinitely, and a quality-rating drop throttles delivery.
• Rate-limit and OTP-verification state must live in a shared store (Redis), not per-node cache, or horizontal scaling silently breaks lockout protection.
• TOTP secret decryption sits on the login hot path; keep key material in a KMS/secret manager rather than .env on app nodes.

Failure modes to design for.

• WhatsApp provider outage or template rejection → users with WhatsApp-only enrollment are locked out. Mitigate with mandatory TOTP enrollment and recovery codes.
• Email deliverability failure → same. Mitigate with a documented fallback factor and a helpdesk reset runbook.
• Queue backlog → OTP arrives after TTL expiry; users retry, burn rate limits, and generate support load. Alert on OTP dispatch p95 latency.
• Lost device with no recovery codes → manual identity-verification reset process; this is the dominant ongoing support cost of any MFA rollout, and it is a process problem this package does not solve.
• Clock drift beyond the verification window → elevated TOTP failures on specific devices; widen to ±1 step at most and monitor the failure rate.
• Unintended bypass via a route or guard that skips the challenge middleware — the highest-severity failure mode and the reason for mandatory bypass testing.
• Secret leakage via logs, error traces, or debug output; scrub factor material from exception reporting.

Ramp-up. A mid-level Laravel engineer is productive on the scaffold within a day and on the extracted module within a week, provided they know Livewire and Filament conventions. Add a security reviewer with auth-protocol familiarity for the initial gate — this is not optional for MFA. Product/design needs a session on enrollment UX and recovery-code communication, since the largest determinant of rollout success is enrollment completion rate, not code quality.

Bottom line. The package is a reasonable reference implementation and a fast greenfield accelerator, but it is not a dependency and not a supported product. Recommend Path C (reference + native Filament MFA) if you are already on Filament 4, Path A only for a greenfield internal tool with a named code owner and a completed security gate, and Path B only with explicit budget for permanent fork maintenance. Do not adopt WhatsApp OTP as anything other than an optional secondary channel.