Fortify Laravel Package

Technical Evaluation

Architecture fit. Fortify is a first-party, frontend-agnostic authentication kernel for Laravel: it ships routes, controllers, actions, and a configurable feature pipeline for registration, login, password reset, email verification, password confirmation, and two-factor authentication (TOTP + recovery codes), with passkey support added in the 1.37 line. It deliberately owns no UI. For a TPM this is the classic "buy the commodity, build the differentiated" split: Fortify removes ~80% of bespoke auth surface area while leaving view/UX, identity policy, and any enterprise IdP integration in your team's hands. The relevant architectural question is not "does it fit Laravel" (it is the reference implementation used by Laravel Starter Kits) but "does our identity model fit a session/guard-centric, single-tenant, first-party auth backend."

Integration feasibility. Low-to-moderate. composer require laravel/fortify, publish config/providers, add the 2FA columns (two_factor_secret, two_factor_recovery_codes, two_factor_confirmed_at) to users, toggle features in config/fortify.php, and wire views or JSON responses via the response contracts. The friction concentrates in four places: (1) existing user tables and password hashes, (2) guard/username configuration including lowercase_usernames, (3) SPA mode over Sanctum (session/CSRF semantics are a recurring source of defects), and (4) email delivery dependencies for verification and reset flows.

Technical risk. Auth is a security-critical, low-tolerance-for-error domain, and Fortify is intentionally "magic-heavy" — behavior lives in pipelines and container-resolved action classes, so a team that doesn't read the source will misdiagnose issues. Version cadence carries real upgrade cost: v1.37.0 dropped PHP 8.1 and Laravel 10, and the project tracks new Laravel majors quickly (Laravel 13 support in 1.34.1). Recent churn in passkeys, 2FA state handling, and recovery-code behavior means the 2FA path deserves explicit regression coverage. Two data points in the package metadata need TPM-level correction: the Dependents: 0 figure is an artifact of how Fortify is consumed (indirectly, via starter kits and framework-level inclusion), not evidence of low adoption; and the "last release 2026-10-06" indicates an actively shipped package, which raises — not lowers — the need to pin versions and review changelogs.

Key questions.

• Which surfaces must authenticate: Blade/Livewire web, SPA, mobile, machine-to-machine? Fortify covers the first three; API tokens are Sanctum's job, not Fortify's.
• Is MFA mandatory for any population? Do we need WebAuthn/passkeys at launch or in a later phase?
• Do we need SSO/SAML/OIDC or SCIM? If yes, Fortify is a partial answer and must be paired with an IdP integration — scope that now, not after cutover.
• What are the audit-logging, session-revocation, and breach-notification obligations?
• Who owns UI, copy, and accessibility for auth screens?
• What is our password hashing and key-rotation posture (Fortify supports encryptUsing / Model::encryptUsing for 2FA secret rotation)?
• What is the brute-force/lockout and rate-limiting policy per route?

Integration Approach

Stack fit. Best fit: Laravel 11/12/13 on PHP 8.2+, greenfield or lightly customized auth, session-based web plus optional Sanctum SPA. Poor fit: apps with a heavily customized, working auth stack, apps requiring federated enterprise identity as the primary login, or non-Laravel services that need auth parity (Fortify won't be the shared identity layer across polyglot services without additional work).

Migration path. Run two tracks depending on starting point.

• Greenfield: scaffold from a Laravel Starter Kit, then strip the UI to your design system. Fortify is the default; treat customization as configuration-first and subclass only where necessary.
• Brownfield: strangler pattern. Inventory every existing auth route and behavior, map each to a Fortify feature flag, and run Fortify's routes alongside legacy routes behind a path/middleware switch. Migrate password hashes without rehashing (bcrypt/argon are compatible; rehash-on-login handles the rest). Migrate existing 2FA enrollment deliberately — either force re-enrollment or decrypt/re-encrypt secrets under the new key. Keep a documented rollback: reversible config flag plus retained legacy routes for one release cycle.

Compatibility. Verify per-target: guard and provider config, username field and case handling, Sanctum stateful domains and CSRF for SPAs, mail transport and queue workers for verification/reset, cache/rate-limiter store, and Octane compatibility (scoped bindings landed in 1.35.0). Confirm the Passkeys feature's middleware and password-confirmation defaults if enabling it, and check any FormRequest::failOnUnknownFields() usage (fixed in 1.37.0).

Sequencing.

1. ADR and threat model; decide feature matrix and opt-outs.
2. Spike on a branch: install, configure, migrate, prove login + reset + 2FA end-to-end with your real mail and session drivers.
3. Data migration and backfill; dual-run against legacy.
4. UI integration (web and/or SPA) with accessibility review.
5. Enable 2FA and passkeys per policy; publish recovery-code UX.
6. Hardening: rate limits, lockout messaging, session regeneration, token revocation on password change.
7. Observability and alerting on auth failure rates.
8. Cutover behind feature flag, then decommission legacy routes.

Operational Impact

Maintenance. Vendor-owned and actively maintained under MIT, with changelogs, releases, PHPStan coverage, and a published security policy. Expect a steady stream of patch releases and dependency bumps; the real cost is the Laravel/PHP upgrade treadmill, since Fortify tracks framework majors and drops old runtimes. Budget a standing "auth maintenance" line item: pin the version, read every changelog, and run an auth regression suite (login, lockout, reset, verify, 2FA enable/disable/recovery, passkey registration) on each bump. Dependabot cooldowns and pinned action SHAs in the repo reduce supply-chain noise but don't remove your review obligation.

Support. First-party documentation on laravel.com/docs/fortify plus an active community; no commercial SLA. Escalation is internal: name a single auth owner, maintain a runbook (how to force-disable 2FA for a locked-out user, how to rotate the app key without orphaning 2FA secrets, how to flush sessions), and capture decisions in an ADR so the next team doesn't re-litigate.

Scaling. Fortify itself is thin and stateless; scale is a function of your session store, database, mail provider, and rate-limiter backend. Horizontal scaling is fine with Redis sessions and a shared cache for rate limiting. Watch: index on the login identifier, mail throughput for verification/reset bursts, and CPU cost of QR/secret generation during 2FA enrollment spikes.

Failure modes and mitigations.

• Guard or provider misconfiguration → silent auth bypass or total lockout. Mitigate with integration tests asserting both allowed and denied paths.
• Mail outage → verification and password reset dead; users stranded. Mitigate with a secondary transport, queue + retry, and a support-assisted reset runbook.
• Cache/rate-limiter outage → lockouts or throttling failures. Mitigate with a documented degraded-mode policy.
• App key/encryption changes → undecryptable 2FA secrets. Mitigate by using encryptUsing for rotation and testing the rotation procedure.
• Route collisions or middleware drift → unexpected public endpoints. Mitigate with an automated route-inventory check in CI.
• Upgrade breakage from pipeline/action changes → auth regressions in production. Mitigate with version pinning, staged upgrades, and the regression suite above.

Ramp-up. A mid-level Laravel developer with no Fortify experience should reach productive contribution in roughly 2–4 days: half a day on config and features, one to two days tracing the request pipeline and action contracts, and the remainder on your specific response customization and test harness. Non-Laravel engineers will take longer because the leverage comes from framework idioms (service container, guards, middleware, events). Plan for one engineer to own the auth spike and ADR, a security review before 2FA and passkeys go live, and a short knowledge-share so on-call can execute the lockout and key-rotation runbooks. Given the opportunity score (~59) and the amount of commodity auth work this replaces, the adoption case is strong — provided the enterprise-IdP question is answered before, not during, integration.