Filament Multifactor Passkeys Laravel Package

Technical Evaluation

Architecture fit. This is a thin Filament panel plugin that delegates the security-critical work — WebAuthn registration ceremonies, credential storage, challenge generation, and assertion signature verification — to spatie/laravel-passkeys. That division of labor is exactly what a TPM wants to see in an auth dependency: the crypto lives upstream in a maintained vendor package, and this repository contributes the Filament-glue layer. Concretely, that means a service provider, a Filament plugin contract registration on the panel, a publishable config and views, translations, a login-flow hook for the MFA challenge, and a profile UI for passkey registration and deletion. The audit surface we own is small and idiomatic.

Fit is binary on stack: it is a Filament 5 plugin targeting Laravel 11/12 and PHP 8.2+. If our admin panel is on Filament 3 or 4, or the app is a non-Filament Livewire/Inertia frontend, this package is out of scope and we should not spend a spike on it. If we are already on Filament 5, the architecture is a near-perfect match for "add phishing-resistant MFA to the highest-privilege surface with minimal bespoke code."

There is one important framing correction for stakeholders: the description markets this as a second factor alongside passwords, but the underlying Spatie package and the WebAuthn ceremonies it enables are also the foundation of passwordless login. The plugin's advertised mode is additive MFA, which is the safer product target — but the ambiguity matters for scoping, because "add a second factor" and "replace the password" are very different rollouts.

Integration feasibility. Installation is nominally a same-day task: composer require, register the plugin in the panel provider, run migrations, publish config and views, set relying-party ID and origin. The true feasibility risk is not package mechanics but deployment configuration. Every environment needs valid TLS with an RP ID scoped to the exact origin, and APP_URL must match. Subdomain topology (admin.example.com vs app.example.com) forces an explicit decision: one shared RP ID or per-panel configuration. Local development requires localhost or a tunnel with a matching origin. These are known, solvable problems, but they are infrastructure and platform-config work that will not appear in a composer-install estimate, and they are the single most common first-day failure mode.

The second feasibility constraint is the enrollment precondition: a user must register a passkey before any passkey-based challenge can succeed. That means the rollout has a chicken-and-egg shape — the feature is useless until enrollment is broad, and enrollment must be prompted through some channel (UI nudge, admin mandate, onboarding step). This is a product sequencing problem more than an engineering one, and it needs to be planned before install, not after.

Technical risk.

• Bus factor 1, zero dependents, 8 stars. There is effectively no third-party production validation, no published threat model, no named security contact. This is the dominant risk and it is not mitigated by reading the code — only by owning the fork and pinning exactly.
• Bleeding-edge pinning. Filament 5 plus a recent Spatie dependency puts us at the leading edge of two version lines simultaneously. A Filament 6 major will strand the plugin until the author ships, and we should assume we are the ones who unblock ourselves.
• Security-critical UX has silent failure modes. WebAuthn defects manifest as enrollment failures, user-verification mismatches, or lockouts — rarely as exceptions in logs. Fallback and recovery paths are the highest-risk unknowns and are not advertised as features of this package.
• Feature velocity is i18n and CI hygiene, not product depth. Release 1.1.0 adds five locales plus Dependabot and workflow standardization. That is a genuinely healthy hygiene signal and a weak depth signal. Expect no admin-side credential revocation UI, no audit trail of registration/assertion events, and no role-based enforcement policy. Those are ours to build or to accept as gaps during audit.
• Metadata anomaly. The source lists a release date of 2026-09-23, which should be reconciled against Packagist tags before we treat the version line as trustworthy for pinning. Trivial to check, but it must be checked before we write a pin into a lockfile.
• Assurance ceiling. This is a UI integration, not an assurance platform. If auditors require attestation policy enforcement, certified authenticator filtering, or FIDO2 metadata service integration, the underlying library must be configured carefully — or we need a commercial solution. Do not let the "phishing-resistant" marketing language imply we get NIST 800-63B AAL3 posture for free.

Key questions for the author / our own review.

1. Is passkey a second factor alongside password, or a passwordless replacement — and can both modes coexist per panel and per role?
2. Are multiple passkeys per user supported, and what is the documented lost-device recovery path? This is the account-lockout question and it blocks rollout.
3. Does the flow enforce user verification (UV), and which userVerification / residentKey / authenticatorAttachment settings are actually exposed in the publishable config vs. hardcoded upstream?
4. Is the credential table Spatie's, and are its migrations stable across minor versions? A table rename upstream is a production incident for us.
5. Multi-panel and multi-domain: one RP ID shared across panels, or per-panel config? What is the supported topology?
6. Rate limiting and session behavior on the assertion endpoint — does the plugin own this, or is it inherited from Laravel's auth scaffolding and therefore ours to configure?
7. Who patches if a CVE lands in the upstream WebAuthn library? Establish the answer before adoption, because "the maintainer" is one person with no SLA.
8. Does the login hook collide with our existing auth customization — SSO/OIDC, LDAP, custom login page overrides, Fortify? Filament panel login is commonly overridden, and two things hooking the same flow is how you get a broken auth path in production.

Integration Approach

Stack fit. Laravel 11/12, PHP 8.2+, Filament 5, Livewire/Alpine for the browser ceremony, spatie/laravel-passkeys for persistence and challenge handling, plus openssl (typically gmp/bcmath) and valid TLS with APP_URL matching the RP origin. If any of those are not true today, stop here — this is not a package we can bend onto an older stack. For a TPM, the practical filter is: confirm Filament 5 first, everything else second. A single composer show filament/filament answers go/no-go before any engineering time is spent.

Migration path. Do not flip the panel to passwordless, and do not make passkeys mandatory on day one. Sequence it as four deliberate stages:

1. Install with enrollment open, login unchanged. Passkey registration is exposed in the user profile; password login remains the only path. Zero lockout risk, and we start accumulating enrollment data immediately.
2. Enroll privileged roles first. Super-admins, finance, support — the accounts whose compromise is an incident. Give a defined window (30 days is defensible) and instrument enrollment completion by role so we can see who is stalling.
3. Enable passkey as an additional factor for enrolled privileged users only. Password plus passkey challenge. Fallback factors (TOTP or email OTP) remain available for anyone not enrolled or on an incompatible device.
4. Evaluate passwordless opt-in only after a full quarter of stable assertion data. Not before. Passwordless is a distinct product decision and this package's advertised mode does not require it.

This ordering eliminates the entire lockout class of incident during rollout — the failure that turns a security win into an executive escalation.

Compatibility. Before committing, verify: the exact Filament 5 minor is pinned and matched; the panel has no competing auth customization that hooks the same login flow (OIDC/SSO, LDAP, custom login overrides, Fortify); the domain strategy supports the RP ID topology the plugin assumes; the Spatie migration table name does not collide with anything existing; and the spatie/laravel-passkeys version resolved by composer is the one whose auth path we read. Also confirm the Packagist version line matches the release notes before pinning.

Sequencing. Plan roughly five weeks to a role-based rollout, with the first week being the decision point:

• Day 1–2 — sandbox spike. Disposable Filament 5 app. Register and authenticate on macOS/Safari, iOS, Windows Hello, Android, and one hardware security key. Confirm the browser ceremony actually completes on each. Log every failure.
• Day 3–5 — source audit. Read the plugin end-to-end (it is small — this is the whole reason the adoption risk is manageable) plus the assertion path in the upstream Spatie package. Write down the failure modes and the recovery gaps explicitly. Decide fork-and-pin vs. track-upstream here. Given zero dependents and a bus factor of one, assume we own the fork, vendor or pin to an exact commit, and enable Dependabot against the Spatie package and its WebAuthn dependency — not just this repo.
• Week 2 — internal pilot with 10–20 users, instrumented for enrollment success rate and login failure rate by browser and OS. This produces the browser support matrix we will need for the helpdesk anyway.
• Week 3–4 — privileged-role enforcement. Stage 3 above, with fallback factors live and a documented recovery procedure tested at least once end-to-end by someone who is not the implementer.
• Week 5+ — publish the runbook, recovery procedure, and support matrix, then roll out by role. Do not open enrollment to everyone until the helpdesk can answer "why can't I enroll on this laptop" without escalating to engineering.

Operational Impact

Maintenance. Treat this as an internally owned component with an upstream benefactor, not as a vendor dependency. Budget 2–4 hours per month for dependency bumps, plus a real spike each time Filament ships a major. Pin exact versions in the lockfile, enable automated dependency PRs, and subscribe to security advisories for spatie/laravel-passkeys and its WebAuthn dependency — the advisories that matter will not arrive via this repository. The good news is the surface we own is small enough that patching or forking is measured in days, not quarters. The bad news is that "small enough to fork" is the same property as "you will probably have to."

Support. The dominant operational cost is not software, it is the helpdesk. Before the privileged-role rollout goes live, we need four things in writing and one thing built:

• A device-loss / recovery procedure. Written, tested, and owned by a named person. This is the highest-probability support ticket and the highest-severity one.
• An admin-side "revoke all passkeys for user X" action. The package does not advertise one and shows no admin credential-management UI. Plan to build this ourselves — it is small, and it is also the control an auditor will ask about during offboarding.
• A browser/OS support matrix, derived from the pilot, published to users so "it doesn't work on my old laptop" has a first-line answer.
• A documented fallback-factor policy. Which users get TOTP or email OTP, under what conditions, and who approves it.
• An audit trail of registration and assertion events. Also ours to build; without it, incident response on an admin compromise is guesswork.

Without these in place, a single locked-out executive becomes an incident, and the passkey rollout gets blamed for it.

Scaling. Runtime cost is negligible. Assertion is a database lookup by credential ID plus a signature verification — no per-request crypto scaling concern, no meaningful added latency, no new stateful service. The DB read is indexed; the signature verify is microseconds to low milliseconds. At our panel's user volumes this is a rounding error against the existing session and query cost. Scaling concerns live entirely in support and onboarding, not in compute.

Failure modes. Rank by probability × blast radius:

• RP ID / origin misconfiguration on deploy — highest probability, and it fails hard: no enrollment, no assertions, and the error surfaced to users is a browser security error with no actionable message. Mitigation: assert RP ID, origin, and APP_URL consistency in a deploy-time health check, not in a README.
• User verification or resident-key mismatch across authenticator types — enrollment succeeds on one platform and fails on another; presents as "it works for me" from the engineer who tested macOS only. Mitigation: the pilot's cross-platform matrix, not assumption.
• Enrollment stall in stage 2 — users quietly never register, so privileged accounts remain single-factor while dashboards say the feature shipped. Mitigation: track enrollment completion as a metric with a named owner, not as a launch milestone.
• Lost device with no recovery path — low frequency, high severity, guaranteed to happen. Mitigation: the tested procedure above, plus a second registered passkey prompted at enrollment time.
• Upstream breakage — a Spatie minor bump, a migration rename, or an advisory with no maintainer patch. Mitigation: exact pinning plus the fork option exercised at least once in a staging environment so we know it works before we need it.
• Filament 6 release — the plugin strands on the old major; the admin panel cannot upgrade without either the author shipping or us forking. Mitigation: accept and plan for the fork; keep the plugin's glue thin so the port is hours.

Ramp-up. For the implementing engineer: half a day to install and configure in sandbox, one to two days to read the plugin end-to-end plus the upstream assertion path, and two to three days to work through cross-platform enrollment and recovery. Call it one engineer-week to confident. The ramp-up cost is not learning WebAuthn — the package deliberately hides that — it is learning the deployment topology (RP ID, origins, TLS, tunnels) and the browser support reality. That knowledge is non-transferable from the package docs, which is why the spike and pilot are load-bearing rather than ceremonial.

For the broader org: the helpdesk needs a short training session and the runbook; users need one clear page explaining what a passkey is, why they are being asked, and what to do if they lose a device. Budget that communications work explicitly — it is the difference between a security improvement users accept and a security improvement users route around.