Filament Multifactor Passkeys Laravel Package

Product Decisions This Supports

• Roadmap: closing the "phishing-resistant MFA" line item on admin surfaces. Filament panels are usually the highest-privilege surface in a Laravel product — super-admins, finance, support impersonation. This package is a scoped, ship-in-a-sprint way to answer the one question that stalls security questionnaires, SOC 2 evidence requests, and enterprise procurement: is privileged access protected by phishing-resistant MFA?
• Build vs. buy on the WebAuthn layer. The genuinely hard part — the WebAuthn ceremony, credential storage, challenge/response validation, browser API handling — is delegated to the underlying Laravel passkey library rather than reimplemented here. What you are "buying" is the Filament-shaped glue: registration UI, per-user passkey management, and the panel login challenge. That glue is typically one to three weeks of Livewire/JS work your team should not own for a single feature.
• Factor selection: passkeys vs. TOTP vs. SMS. Passkeys are phishing-resistant, eliminate shared secrets and one-time-code interception, and remove SIM-swap exposure. It is the strongest factor available without hardware-token logistics, and it opens a passwordless path later — a real UX and support-cost win for daily-login internal tools.
• Segmentation: privileged roles first, everyone else optional. The plugin is additive to existing auth, not a replacement, which supports a defensible rollout: mandatory for super-admins and finance, opt-in for the long tail, TOTP/email OTP retained as fallback. That sequencing is a product decision, not an engineering one, and this package makes it cheap to defer.
• Support-cost and incident reduction. Fewer password resets, fewer credential-stuffing and admin-takeover incidents. If you can attach a number to reset volume or a past ATO event, this shifts from "security nice-to-have" to a straightforward ROI case.
• Compliance and sales enablement. Passkeys map cleanly to NIST 800-63B authenticator assurance and CISA/OMB phishing-resistant MFA guidance — useful language at the security-review stage of enterprise deals, especially fintech, health, and public-sector-adjacent segments.
• Localization as a market signal. 1.1.0 adds five locales (az, fa, hi, pt, uz), contributed externally and credited. If you sell into non-English markets, that is a small but real signal the auth UX won't be a lone-English island.
• Explicitly not supported decisions: workforce IAM, SSO, directory sync, or org-level auth policy. Do not let this package get scoped into an enterprise-identity roadmap conversation.

When to Consider This Package

Adopt when all of the following hold:

• You are on Filament 5. This is a v5-only integration; Filament 3/4 are out of scope and the major version is a hard pin.
• Your admin surface is genuinely high-privilege and you have a compliance, procurement, or incident driver — not just "MFA is good practice."
• You want self-service passkey registration and management inside the panel rather than hand-rolling Filament resources around the underlying passkey library.
• Your team lacks in-house WebAuthn/browser-API depth and would rather not acquire it for one feature.
• You are comfortable treating this as a small, forkable dependency: MIT licensed, small enough to audit end-to-end, vendorable or pinnable to an exact commit.
• You will keep TOTP or email OTP as a fallback factor for users without a compatible device, and you have a written device-loss recovery procedure before rollout — not after the first locked-out executive.

Look elsewhere — or build in-house — when:

• Version or stack mismatch. Filament 3/4, a non-Filament Laravel app, or Inertia/Livewire frontends outside the Filament ecosystem.
• Adoption risk is unacceptable. Eight stars and zero dependents means effectively no third-party production validation and no published threat model or named security contact. If your org requires a maintained-with-SLA dependency, this fails that bar regardless of code quality.
• Bus factor. Single maintainer. The 1.1.0 release is Dependabot bumps, CI standardization, and translations — healthy hygiene, weak evidence of maintenance depth. Assume you own the fork.
• High-assurance requirements. If auditors demand attestation policy enforcement, certified-authenticator filtering, or FIDO2 metadata service integration, this is a UI integration, not an assurance platform.
• You need full workforce IAM. No SCIM, no SAML/OIDC SSO, no organization-level policy, no admin-forced re-enrollment. If SSO plus directory sync is on the roadmap, evaluate Fortify/Socialite, WorkOS, Auth0, or Okta — a passkey plugin complements those, it does not substitute for them.
• You need SMS/email OTP as first-class factors in the same package. You will wire that separately.
• Your deployment can't give a stable RP ID and HTTPS origin. Multi-subdomain (admin. + app.) and local-dev origin problems are deployment configuration, not package configuration, and they are the most common first-day failure.

How to Pitch It (Stakeholders)

To executives and the security-review audience. This is a small, MIT-licensed plugin that adds phishing-resistant, biometric-or-hardware-key sign-in to our admin panel, built on the WebAuthn standard and an established underlying Laravel passkey library. It closes the "phishing-resistant MFA" line item that blocks security questionnaires and enterprise deals, and it reduces password-reset load and admin account-takeover risk. The cost is engineering time, not license spend — days, not a quarter. The honest caveat: it is a young, low-adoption package maintained by one person. We mitigate by pinning the version, treating the upstream passkey library as the dependency of record, and keeping our fork path open. Recommended ask: approval for a two-day spike and a scoped pilot, not a blanket platform commitment.

To engineering. This is a thin Filament adapter, not a crypto implementation. The WebAuthn ceremony, credential storage, and challenge validation live in the upstream passkey library; this package contributes panel login integration, passkey registration, and per-user management UI, plus translations and standardized CI/test workflows. It is the Livewire/Filament glue you would otherwise write and maintain yourselves. Integration is publish-and-configure: composer require, register the plugin on the panel provider, run migrations, publish config, set RP ID and origin correctly. It requires PHP 8.2+, Laravel 11/12, valid TLS, and HTTPS origins that match APP_URL — budget for local-dev origin friction in onboarding docs. Before committing we run a two-day spike: verify Filament 5 compatibility against our panel, confirm no collision with existing auth customization (SSO, LDAP, custom login overrides) or the upstream migration table name, test enrollment and assertion on macOS/iOS, Windows Hello, Android, and one hardware key, and read the source end-to-end — it is small enough to audit fully, which is exactly why the adoption risk is manageable rather than disqualifying. Then we pin an exact version, enable Dependabot and advisories on the upstream library, and plan the operational work the package does not advertise: an admin-side "revoke all passkeys for user X" action, a helpdesk recovery runbook, and a browser/OS support matrix. Rollout sequence is deliberate — enrollment enabled first with password login unchanged, privileged roles prompted next, passkey enforced as an additional factor only, and passwordless opt-in evaluated after a full quarter of stable enrollment data. That ordering eliminates the lockout class of incident during rollout.