2Fa Webauthn Laravel Package

Product Decisions This Supports

• Roadmap: phishing-resistant MFA. Whether to ship WebAuthn/FIDO2 security keys and platform authenticators as a second factor (after password) in the next one to two releases, versus staying on TOTP/SMS. This package is a bounded way to test demand for that capability.
• Build vs. buy on the WebAuthn ceremony. Registration/assertion flows, CBOR/COSE handling, challenge lifecycle, and credential storage are easy to underestimate. Adopting a plugin keeps the crypto surface out of your backlog and lets the team spend the sprint on enrollment UX, recovery, and policy instead.
• Reuse vs. replacement of the 2FA abstraction. The package plugs into scheb/2fa, so the decision is really "extend the 2FA provider contract we already have" versus "introduce a new auth stack." That is a much cheaper decision to reverse than a custom implementation.
• Compliance-driven scope. Useful when a requirement names phishing-resistant authenticators (NIST 800-63B AAL2/AAL3 language, PSD2 SCA, enterprise security questionnaires, SOC 2 access-control evidence). This gives a concrete artifact to point auditors and customers at.
• Segment prioritization. Best fit for privileged/admin users and high-value step-up moments first (payouts, key rotation, data export), consumer-wide passkeys later. This package supports the narrow-first rollout pattern.
• Fallback and recovery policy. Forces explicit decisions on recovery codes, TOTP fallback, device naming/revocation, and what happens when a user loses their only key — all of which are product surfaces, not implementation details.
• Anti-decision: it does not support a "passkeys as primary login" roadmap. It is second-factor only; treating it as a passwordless foundation will create rework.

When to Consider This Package

Adopt when most of these are true:

• You are already running scheb/2fa (note: that is a Symfony bundle — this is not a Laravel-native package, so a Laravel team should treat integration as a real, scoped project or look at Laravel-native alternatives).
• You need WebAuthn as a second factor only, and TOTP/recovery codes remain acceptable fallbacks.
• Your team can own the enrollment UI, credential metadata, and support runbooks; the package supplies protocol, not product.
• You are comfortable with a single-maintainer, MIT-licensed dependency at low adoption, and can pin versions plus carry a fork if needed. Note the maintainer does ship targeted patch releases that track upstream cose-lib changes (v3.03 removed the non-standard Ed256/Ed512 algorithm support), so the pinning discipline matters in practice: treat minor releases as reviewable, not auto-mergeable.
• Your security review accepts a small dependency over a homegrown crypto implementation — usually the right trade.

Look elsewhere when:

• You need passwordless / passkeys-first. Evaluate web-auth/webauthn-lib directly, laragear/webauthn, Laravel Fortify plus a WebAuthn library, or a managed provider (Corbado, Passage, Auth0/WorkOS passkeys) if you want SLAs and cross-device UX handled.
• Procurement or vendor-risk review is strict. 15 stars, 0 dependents, and no commercial support is a bus-factor conversation you will lose in an enterprise review without an internal owner.
• You need attestation policy enforcement, managed-device or enterprise attestation, or per-authenticator policy — verify support explicitly before committing.
• You are Laravel-first and want zero adapter code. The glue cost likely exceeds the value versus a native package.

Two release-specific checks before adoption or upgrade:

• Algorithm inventory. v3.03 drops non-standard Ed256/Ed512 in favor of the standard COSE algorithm IDs. The maintainer expects no BC impact, but if any existing credentials were registered under those legacy IDs they can stop verifying — audit registered credential algorithms before upgrading, or accept forcing re-enrollment for a small population. New deployments are unaffected.
• Maintenance signal. A small, targeted compatibility patch is mildly positive evidence against the maintenance concern above; it does not by itself offset the bus-factor risk, so keep the named-owner requirement.

How to Pitch It (Stakeholders)

To executives: This is the lowest-cost route to phishing-resistant MFA for our privileged and admin accounts — the single highest-leverage control against credential phishing and session theft. It is MIT-licensed with no per-seat fees, and it slots into the 2FA framework we already operate, so we buy the protocol work instead of building it. Expect roughly a sprint of integration and UX, versus multiple sprints for a from-scratch implementation, with a clean fallback to existing TOTP if we reverse the decision.

To engineering: The plugin implements WebAuthn registration and assertion as a provider for scheb/2fa, so we keep our existing auth wiring and own only the UI, credential metadata, and recovery policy. Constraints to confirm up front: it is a Symfony-ecosystem integration (Laravel needs an adapter), it is second-factor only, and it is a small single-maintainer dependency that ships occasional upstream-driven patches (v3.03 removed non-standard Ed256/Ed512 algorithm IDs), so pin versions and review releases rather than auto-updating.

Risk framing to state plainly: low adoption and bus factor are the real costs, not license or performance. Mitigate with a thin internal interface around the provider so it is swappable, integration tests around the ceremony, an explicit TOTP/recovery fallback, and a named owner who can fork. If procurement pushes back, the fallback plan is a direct web-auth/webauthn-lib implementation or a managed passkey vendor — both more expensive, so we should decide with that delta in view.