Fortify Laravel Package

Product Decisions This Supports

• Build vs. buy for authentication. Fortify is the buy-side default for Laravel apps: it ships the backend of registration, login, password reset, email verification, password confirmation, and two-factor authentication (TOTP + recovery codes) as first-party, MIT-licensed code. A PM can retire "write our own auth" from the roadmap and reallocate that engineering time to product surface.
• Frontend/UX ownership. Because Fortify is frontend-agnostic, it unblocks the decision to ship a custom-branded auth experience (Blade, Livewire, Inertia/React/Vue, or a mobile client hitting JSON endpoints) without giving up a hardened backend. It decouples "what the login screen looks like" from "how credentials, sessions, and 2FA are handled."
• Roadmap: passwordless / passkey authentication. Recent releases add passkey (WebAuthn) support alongside TOTP 2FA and recovery codes. This is the decision input for a "modern auth" initiative — you can sequence password → 2FA → passkeys without a re-platform.
• Multi-client / API-first product strategy. Fortify supports SPA authentication via Sanctum and returns JSON responses for 2FA flows, which directly supports the decision to serve web + mobile + partner API from one identity model rather than forking auth per client.
• Security & compliance posture decisions. Encrypted 2FA secrets, the ability to honor Model::encryptUsing for app-key rotation, token revocation on password change, configurable rate limiting/lockout, and a documented security disclosure policy are all pre-built answers to questions that appear in SOC 2 / pen-test / vendor-security reviews.
• Scope decisions on account lifecycle. Feature toggles (Features::canUpdatePasswords(), 2FA enable/disable, profile updates, recovery-code regeneration) let a PM turn capabilities on per plan tier or per cohort instead of shipping everything at launch.
• Operational readiness decisions. Scoped bindings for Octane compatibility and ongoing PHP 8.4/8.5 and Laravel 12/13 support mean the "do we adopt Octane / upgrade the framework" decisions don't get blocked by auth-layer rewrites.
• Use cases to prioritize: B2C SaaS with self-serve signup and optional 2FA; B2B apps needing per-user MFA for buyer security questionnaires; internal tools where centralized password policy and email verification matter more than social login; API products needing token issuance plus a 2FA challenge step.
• Explicitly out of scope (so don't plan for it here): social/OAuth login (Socialite), enterprise SSO/SAML/OIDC (dedicated package or managed IdP), billing/teams (Cashier/Jetstream), and fine-grained authorization/RBAC (app-level or a permissions package). Treat these as separate line items, not Fortify gaps.

When to Consider This Package

Adopt when:

• You are on a supported Laravel version (currently Laravel 12/13 per recent releases) and PHP 8.2+.
• You need authentication but want to own the UI/UX — a design-led product, a native mobile app, or an existing component library.
• Your requirements include multi-factor auth, recovery codes, email verification, password reset, and login throttling — the exact checklist Fortify already implements.
• You have multiple clients (web SPA, mobile, API) and want one backend auth contract rather than three.
• You are a small team where "one engineer owns auth" is a single point of failure and a first-party, actively maintained package is preferable to bespoke code.
• You anticipate a passkey/passwordless roadmap; adopting Fortify now avoids a later migration.

Look elsewhere (or scope differently) when:

• You want a working, styled auth UI today with zero frontend work — evaluate the Laravel Starter Kits or Jetstream, which are UI layers that already consume Fortify. Choosing Fortify directly means you are signing up to build the frontend.
• You need social login as a launch-blocking requirement — plan Socialite as an adjacent integration, not a Fortify deliverable.
• Your buyer requires enterprise SSO (SAML, SCIM, OIDC federation) — that is a separate procurement/build decision; Fortify will not satisfy it.
• You want fully outsourced identity (managed Auth0/Clerk/Cognito-style) for multi-product or non-Laravel estates — Fortify keeps identity in your app and your database.
• Your needs are genuinely trivial (single internal tool, one shared login, no 2FA) — Laravel's built-in auth scaffolding may be enough, and Fortify is unneeded surface area.
• You need guarantees outside the maintainers' release cadence (formal SLA, indemnification, vendor support contract) — this is community-supported MIT software.
• Metric caveat: treat the reported "0 dependents" as a measurement artifact, not a signal. Fortify is the auth engine behind Laravel's own starter kits, and the release history shows continuous security-relevant maintenance. Judge adoption by ecosystem integration, not this field.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version:

Authentication is a mandatory, security-sensitive, non-differentiating feature that we would otherwise build and maintain forever. Laravel Fortify is the official, MIT-licensed, frontend-agnostic auth backend for Laravel, maintained by the framework's own team and used by Laravel's starter kits. Adopting it removes weeks of initial build and, more importantly, removes ongoing ownership of password reset, email verification, two-factor authentication, recovery codes, rate limiting, and passkey support. There is no license cost, no vendor lock-in (the code lives in our repository and we can fork it), and no data leaves our infrastructure. It also de-risks the roadmap: passkeys and multi-client/API auth become configuration and UI work rather than re-architecture.

For engineering — the practical case:

• We write controllers and views; Fortify owns credential validation, session/2FA challenge flow, TOTP secret encryption, recovery codes, throttling, and password-reset token handling — the parts where bugs become incidents.
• Frontend-agnostic by design: the same backend serves Blade, Inertia, or JSON/SPA clients (with Sanctum), so web and mobile don't diverge.
• Actively maintained: recent releases cover passkeys, Octane scoped bindings, app-key rotation via encryptUsing, canUpdatePasswords(), and PHP 8.5 / Laravel 13 compatibility. It is not a stagnant dependency.
• Extension points exist where we'll need them: overridable recovery-code class, container-resolved 2FA redirect, customizable response classes — so customization doesn't mean forking.
• It does not include social login, SAML/SSO, or RBAC. Those are separate, explicitly budgeted items — no surprises later.

Trade-offs to state up front (credibility, not hedging):

• Cost is frontend work, not backend work — the estimate should be scoped as UI/UX plus configuration, not "install package, done."
• Version upgrades track the Laravel major (Laravel 13 support landed in v1.34.x), so auth work should be included in every framework-upgrade cycle.
• Support model is open source: our mitigation is that it is first-party, MIT, and small enough to read and patch.
• Security ownership stays with us: Fortify provides the primitives; enforcing password policy, MFA mandates per plan tier, and audit logging remain product decisions.

Suggested success criteria for the decision: auth shipped behind a feature flag within the current cycle; 2FA and passkey availability exposed to the intended cohorts; zero bespoke code handling credential verification or secret storage; and an auth layer that survives the next Laravel major with configuration changes only.