Filament Passkeys Laravel Package

Product Decisions This Supports

• Feature decision — passwordless admin login. Lets you ship passkey enrollment (register/manage credentials in a Filament profile page) and passkey-based login on the Filament auth screen without writing WebAuthn ceremony code yourself. This is the core capability, and it's the one that meaningfully changes your security posture versus another password policy tweak.
• Roadmap sequencing — security hardening vs. new features. If your security backlog already contains "phishing-resistant MFA for admin users," this is a candidate to close that item in days of integration work rather than a sprint of crypto plumbing. It competes directly with: doing nothing, mandating TOTP (already native in Filament v4's MFA), or adopting enterprise SSO.
• Build vs. buy — buy the glue, own the risk. The genuinely hard, standards-bound work (challenge generation, attestation verification, signature counter handling, credential storage) almost certainly sits in an underlying WebAuthn PHP library, not in this plugin. What you're buying is the Filament-specific integration surface: resource/page wiring, migrations, UI affordances. Price that as glue, and budget accordingly — a thin package from a single author is a fork-and-maintain candidate, not a vendor relationship.
• Use case fit — internal and client-facing admin panels. Strongest for internal staff tools and agency-built client Filament apps where the user population is small, known, and reachable for support. Weakest for consumer-scale sign-up flows, where recovery UX and account enumeration concerns dominate.
• Positioning and sales enablement. "Phishing-resistant authentication on the admin surface" is a concrete, verifiable answer to security questionnaire line items and a differentiator in procurement conversations — especially for buyers who ask about MFA but would be satisfied with TOTP once you explain the tradeoff. Decide whether you're claiming phishing resistance (passkeys) or just MFA (TOTP) before you put it in a deck.
• Support-cost hypothesis. Passkey adoption should reduce password-reset tickets and credential-stuffing incidents for the covered user base. This is testable: instrument reset volume and failed-login rate for the pilot cohort and treat it as a go/no-go input for wider rollout.

When to Consider This Package

Consider it when all of the following hold:

• You are on Filament and the target surface is the admin/panel login, not a public consumer auth flow.
• Your admin user base is small, internal, and supportable — you can reach a locked-out user and run a recovery path manually if needed.
• You have or can designate a fallback auth path (password + TOTP, or SSO) so a lost device is an inconvenience, not an outage.
• You accept the maintenance profile: 3 stars, 0 dependents, single maintainer. You are an early adopter. Plan for a time-boxed spike (1–3 days) to read the source, confirm test coverage, verify the WebAuthn core dependency is actively maintained, and confirm it survives a Filament minor upgrade.
• You're willing to vendor/fork if the author steps away. Confirm the license permits it and that migrations are publishable.

Look elsewhere when:

• You need enterprise identity: SAML/OIDC SSO, SCIM provisioning, conditional access, device trust policy. Passkeys are not a substitute for an IdP at that scale.
• You need attestation policy enforcement (e.g., restricting to specific authenticator classes) or audit-grade credential lifecycle reporting. That's a WebAuthn library + custom work, not a plugin.
• Your requirements include consumer-scale recovery, cross-device onboarding UX, or account-recovery flows — build on a maintained WebAuthn library and own the product surface.
• You need commercial support, an SLA, or a security review with a named counterparty. Zero dependents means zero downstream validation; you will be the first to hit most edge cases.
• Filament's native MFA already satisfies the requirement. If the actual control objective is "MFA on admin," TOTP is a strictly lower-risk delivery. Passkeys only win if the objective is specifically phishing resistance.

How to Pitch It (Stakeholders)

For executives (one paragraph). Passkeys replace passwords on our admin panel with device-bound, phishing-resistant credentials — the same mechanism behind "sign in with your face or fingerprint" at major consumer platforms. The integration is small and reversible: it sits on top of an existing, standards-based WebAuthn implementation and adds a management screen plus a login option, scoped to a pilot group first. Expected upside is a measurable reduction in password-reset load and credential-stuffing exposure on the most privileged accounts; expected cost is a few days of engineering plus an ongoing ownership commitment. The caveat is supplier maturity — the plugin is early-stage with a single maintainer and no downstream adoption — so we should proceed as an early adopter, keep a fork-ready posture, and gate wider rollout on pilot metrics.

For engineering (summary). Thin Filament glue over a WebAuthn library: credential registration and management in the user profile, passkey assertion on the panel login, plus migrations and config. Verify before committing: which WebAuthn core it depends on and whether that library is maintained, test coverage and CI, behavior on Filament minor upgrades, and the recovery/fallback path when a user loses their device. Assume we may own this code within 12 months.

The ask. Approve a short spike (read source, confirm dependency health, run the pilot integration behind a feature flag for one internal team). Bring back pilot data — adoption rate, reset-ticket delta, failed-login delta — plus a build-vs-fork recommendation.