Filament Access Control 2Fa Laravel Package

Technical Evaluation

Architecture fit: Conceptually strong, evidentially weak. The capability described — TOTP 2FA with authenticator apps, recovery codes, and enforcement scoped to users/roles/panels — maps directly onto a gap most Laravel/Filament admin panels have: no MFA in front of the highest-privilege surface in the application. As a TPM, that framing matters more than the code, because "MFA on admin" is a control auditors ask for (SOC 2 CC6.x, ISO 27001 A.9/A.5) and a scope-reduction lever (fewer privileged users to monitor). What cannot be assessed is whether the package actually implements that control safely: there is one release (v1.0.1), it is a rename to enable publishing, and there is no README, changelog, CI, issue history, or version-support matrix in evidence. Treat the security-relevant behavior as unvalidated until a spike reads the source.

Integration feasibility: Mechanically moderate. Filament integration implies a plugin/service provider, a registration call in the Panel provider, middleware on the auth path, published config, and likely a migration for recovery codes and 2FA state on the users table. That is a small surface, but it touches the authentication pipeline, which means the blast radius of a defect is "admins locked out" or "control bypassed," not "styling looks wrong." Two compatibility facts must be established before any estimate: which Filament major is supported (Filament v3 was a breaking rewrite; a package frozen at April 2024 may or may not track it), and which Laravel majors are in the require constraints.

Technical risk: High for the intended use case. Auth code is the one category where low adoption is a security risk rather than just a maturity signal — 0 stars means no community scrutiny of the TOTP verification path, and no evidence of a disclosure process. Specific things a reviewer should demand: recovery codes hashed (not plaintext), TOTP secrets encrypted at rest and not logged, replay protection/drift window bounded, rate limiting and lockout on verification attempts, and no bypass via impersonation, API routes, or console. Supply-chain risk is also elevated: an unpublished-then-renamed package on a critical path, with no maintainer identity that legal or security can hold accountable. Note too that the last release is ~a year old against a fast-moving Filament ecosystem.

Key questions:

1. Which Filament and Laravel majors are supported, and is the supported version the one we run?
2. Which library performs TOTP generation/verification, and how are secrets and recovery codes stored (encrypted? hashed? salt?).
3. Where does enforcement live — middleware, panel-level, policy — and can it be bypassed by impersonation, direct route access, or service accounts?
4. What happens when a user loses both device and recovery codes; is there an audited admin reset path, or a support incident waiting to happen?
5. Is there any test suite, and does it cover the verification path?
6. Does the package emit audit events or integrate with our logging, or do we need to add that?
7. Is there a named maintainer, a security contact, and any commitment beyond "published"?
8. Can the feature be delivered in-house in a comparable timebox (TOTP + recovery codes + Filament gate is not trivial, but is bounded)?

Integration Approach

Stack fit: Only viable if the answer to question 1 is "yes, our versions." Before that is confirmed, do not slot this into a roadmap — a Filament major mismatch converts a one-day pilot into a fork-and-maintain commitment, which changes the build-vs-buy math entirely.

Migration path: Introduce it as an additive control on an internal, low-traffic admin panel first — never as the initial gate on a customer-facing or payments-adjacent surface. Sequence the rollout so 2FA is optional-then-enforced per panel, not globally on day one, so a defect degrades to "some admins can still get in" rather than "nobody can." For existing installs the rename is the immediate hazard: confirm whether v1.0.1 changed only the Composer name or also the PSR-4 namespace, service provider, config keys, and publish tags; then clear Composer cache, update lock files, re-run package:discover, and re-publish config/migrations against the new tags. Do not run old and new names concurrently.

Compatibility: Verify against a clean Laravel skeleton matching production — PHP version, Laravel major, Filament major, Livewire — plus a check that auto-discovery registers and that publishing migrations doesn't collide with an existing users table (2FA state can live in a separate table; confirm which).

Sequencing:

1. Timeboxed spike (≤1 engineer-day): install, register the plugin, enable 2FA on one test panel, enroll a user, log in, exhaust a recovery code.
2. Source read focused on the security questions above; write the findings down, because they are the artifact the security review will consume.
3. Define an application-level contract (an interface your code calls, plus one integration test at that boundary) so the vendor never leaks into domain logic and removal is a config change.
4. Staging pilot for one release cycle with a documented lockout-recovery runbook.
5. Production only if the spike and source read pass; otherwise fall back to in-house implementation or a maintained alternative.
6. Record the decision and the exit criteria in the decision log either way.

Operational Impact

Maintenance: Effectively unsupported. A single 2024 release with no visible activity means we inherit the maintenance obligation the moment we adopt it on a critical path. Budget the realistic cost: either an engineer-hour per Filament/Laravel upgrade to validate compatibility, or a planned fork. For a TPM, the honest framing is "we are adopting code, not a vendor."

Support: No vendor to escalate to. Support becomes an internal runbook covering: how an admin enrolls, how a lost device is reset (and who authorizes it), how recovery codes are reissued, and how to disable enforcement during an incident. Without that runbook, the first lockout becomes an outage with no documented remedy — this is the single most likely operational failure and it is entirely preventable.

Scaling: Negligible. TOTP verification is a cheap HMAC computation on the login path; there is no request-path, queue, or memory concern at any realistic admin-panel scale. Scaling is not a reason to reject this.

Failure modes:

• Admin lockout when 2FA is enforced before recovery paths are proven — highest-likelihood, highest-impact.
• Silent bypass if enforcement lives in a place that impersonation or direct routing skips; discovered only in an audit.
• Secret/recovery-code exposure if storage is unencrypted or if secrets land in logs or error trackers.
• Silent de-registration after upgrade from a stale bootstrap/cache/packages.php — a runtime "class not found," not a deploy-time failure.
• Filament major upgrade breaking the plugin, with no upstream fix forthcoming.
• Dependency confusion on the abandoned old Composer name if anything remains pinned to it.

Ramp-up: Low for the integration itself; high for the decision. Roughly a day of engineering to spike and a few hours of security/TPM review to accept or reject. The TPM deliverable here is not the integration — it is a written decision with a threat model, acceptance criteria, an exit plan (interface + boundary test), and a rollback path, so that when the package is eventually abandoned — the base rate for 0-star, single-release repositories is not favorable — removing it is a scheduled task rather than an incident.