Filament Passkeys Laravel Package

Product Decisions This Supports

• Authentication roadmap sequencing. This package lets you commit to a passkey roadmap without committing to a build. The decision it unlocks is direction, not effort: do we move the panel toward phishing-resistant login (optional factor → opt-in passwordless → enforced for privileged accounts), and in what order? The three config levers (->passwordlessLogin(), managementOnly(), isRequired:) map one-to-one onto those stages, so you can gate each stage behind a feature flag and a support-readiness checkpoint rather than a rewrite.

• Build vs. buy for the WebAuthn ceremony. The honest framing is three options: (a) adopt this plugin, (b) build directly on laravel/passkeys with your own Filament UI, (c) build the full stack in-house. Option (c) is a multi-week security project with ongoing cryptographic review burden — reject it for an internal admin panel. Option (b) is the real comparison: the plugin's defensible value is the login button, browser autofill, MFA provider integration, and profile management UI, i.e. roughly "a sprint of Filament glue." If your team already has a strong opinion on the login UX, (b) is credible. If you want it next month, this is (a).

• Security posture as a sales/audit asset. Passkeys are the cheapest credible answer to "phishing-resistant MFA" appearing in enterprise security questionnaires, SOC 2 evidence requests, and cyber-insurance underwriting. That is a go-to-market decision, not just an engineering one — and it's the strongest argument for scoping this to a panel your customers or auditors actually see.

• Support-cost reduction. Password resets and MFA lockouts are a measurable line item in helpdesk volume. Passkeys reduce reset frequency but raise lockout severity — so the decision this supports is a paired one: adopt passkeys and fund a fallback factor (EmailAuthentication) plus an account-recovery runbook in the same release. Never ship one without the other.

• Blast-radius scoping. Because the change lands on the User model as a trait, this is an application-wide decision disguised as a panel feature. It surfaces the question of whether your admin panel and customer-facing surfaces should share an identity model at all — often a worthwhile architectural conversation to force early.

• Vendor-risk acceptance. With 3 stars, 0 dependents, a single maintainer, and a pre-1.0 upstream (laravel/passkeys ^0.4) hard-pinned to Filament v5, adopting this is formally a decision to accept bus-factor risk. The mitigation is cheap and should be decided now, not later: MIT license plus a small code surface means vendor-and-fork is a realistic contingency. Write that down as the exit plan before you ship.

When to Consider This Package

Good fit — adopt with normal diligence:

• You are on Filament v5 (non-negotiable; this is hard-pinned) with a single panel, standard Authenticatable user, default guard, and stock ->login() / ->profile().
• The surface is an internal admin or back-office panel where a lost-device lockout costs minutes of helpdesk time, not revenue or a customer incident.
• You want a differentiated login experience (browser autofill, one-tap sign-in) without owning WebAuthn cryptography.
• You have an owner who will re-test on Filament minor bumps and a plausible path to fork if upstream goes quiet for two quarters.
• You already accept, or are prepared to accept, the laravel/passkeys review as your real security review — this plugin is thin glue, so that's where the scrutiny belongs.

Look elsewhere — or build on laravel/passkeys directly:

• Filament v4 or earlier. Not supported. Full stop.
• Customer-facing, internet-scale authentication with no named internal owner. The maturity profile (pre-1.0, single maintainer, no evidence of production use at scale) is disqualifying for an unowned public auth path.
• Multi-guard, SSO-brokered, or heavily customized login/profile flows. Fit degrades fast here, and the failure mode is subtle config drift rather than a clean error.
• Fortify already present. Not a dealbreaker, but a trap: config/fortify.php silently overrides config/passkeys.php. If you can't guarantee one source of truth, defer.
• You need audit logging, session-invalidation semantics on credential removal, or admin-side credential reset. These are unstated in the README. Assume not included; scope them as your own work or as a fork.
• You need a tested compatibility matrix published upstream. It isn't. If procurement requires one, you're producing it yourself.

How to Pitch It (Stakeholders)

To executives (one paragraph): We can offer modern, phishing-resistant sign-in on the admin panel as a configuration change instead of a security project — roughly a sprint of integration against the standard Filament multi-factor system, built on Laravel's own passkeys package rather than bespoke cryptography. It's MIT-licensed and small enough that we can take ownership of the code if the maintainer steps away; the real cost is not the build, it's the recovery process and the security review, both of which we should fund in the same release. Recommendation: adopt on the internal admin panel first, staged from optional second factor to enforced for privileged accounts, and treat customer-facing login as a separate decision with a separate owner.

To engineering (the short version): Four mechanical steps — composer require, publish the upstream migration, add PasskeyUser + PasskeyAuthenticatable to User, register the plugin. Then the part that actually determines success: correct Relying Party ID, allowed origins, user-handle secret, and throttling — in config/passkeys.php, or config/fortify.php if Fortify is in play, never both. Two documented footguns to encode in the rollout: managementOnly() is incompatible with isRequired: true (users get stranded on the setup page), and without a fallback factor a lost device is a hard lockout. Budget the security review against laravel/passkeys, and decide the fork contingency before launch — not after the maintainer goes quiet.

What to ask for in the same breath as approval: a named internal owner, a break-glass recovery runbook, a fallback MFA provider in the same release, and a decision on whether enforcement is scoped to super-admins first. Approving the plugin without those four things is approving an outage with a nice login page.