Nova Google2Fa Laravel Package

Product Decisions This Supports

• Build vs. buy for authentication security: A maintained Laravel 2FA package lets the team buy the commodity layer (TOTP enrollment, recovery codes, challenge flow) and spend engineering capacity on differentiated product work instead of re-implementing RFC 6238 and recovery-code UX.
• Roadmap sequencing for security/compliance work: 2FA is usually a gating item for SOC 2, ISO 27001, enterprise security questionnaires, or payment/healthcare procurement. Having this package available shortens the path to "2FA available" from a multi-sprint build to a configuration-and-integration task.
• Feature decisions it unlocks: enterprise tier packaging (SSO + mandatory 2FA), admin-enforced 2FA policies, step-up authentication for sensitive actions (payouts, API key creation, data export), and account-recovery flows.
• Extensibility / fork-avoidance decision: v1.0.1's ability to override the User2Fa class means custom persistence (tenant-scoped tables, extra audit columns, existing users schema constraints, custom casts or soft deletes) can be supported through configuration rather than a hard fork. That directly de-risks the "we adopt it, then patch it forever" failure mode and keeps the upgrade path to future releases open.
• Buy vs. extend trade-off: the override hook is the deciding signal for teams whose data model doesn't match the package's default assumption — it converts a "build our own to match our schema" decision into an "adopt and override" decision.
• Vendor/dependency posture: a 1.0.x release cadence with small, additive changes suggests a stabilizing API — reasonable to commit to for a security-critical surface, though still early enough to warrant a pinned version and a review of the maintainer's responsiveness.

When to Consider This Package

Consider it when:

• The product is Laravel/PHP and the team wants first-party-style 2FA without owning the cryptographic and UX surface area.
• 2FA is on the roadmap as a compliance checkbox, an enterprise sales requirement, or an account-takeover mitigation — and speed matters more than bespoke UX.
• The default User2Fa model fits or your divergence is limited to schema/behavior that class inheritance can absorb (extra columns, scopes, tenant keys, audit hooks) — this release explicitly supports that.
• You want a package small enough to audit internally in an afternoon rather than a large identity platform.
• You need a fallback if you later outgrow it: a well-scoped 2FA layer is comparatively easy to replace, unlike an embedded identity provider.

Look elsewhere when:

• You need a full identity platform — SSO/SAML/OIDC, SCIM provisioning, policy engines, risk-based authentication, or passwordless/WebAuthn-first flows. This is a 2FA component, not an IdP.
• You require passkey/WebAuthn or hardware-token support as the primary factor; verify coverage before committing.
• Your User2Fa needs are structurally different (e.g., 2FA state must live on an external identity service, or enrollment spans multiple models/services) such that overriding one class becomes a rewrite.
• You need vendor-backed SLAs, security certifications, or commercial support for procurement — an open-source package with a single maintainer is a supply-chain and bus-factor consideration that must be documented and accepted.
• Your stack isn't Laravel, or you're on an unsupported Laravel/PHP version.
• The team cannot absorb the security review burden: 2FA code paths deserve threat modeling, rate-limit review, recovery-code handling checks, and secret-at-rest encryption verification regardless of who wrote them.

How to Pitch It (Stakeholders)

To executives / budget owners: Two-factor authentication is a recurring line item in enterprise security questionnaires and a prerequisite for several compliance frameworks. Rather than funding a multi-sprint build of a solved problem, we can adopt a focused Laravel package, integrate it, and put our engineering time into the product features that actually differentiate us. The near-term cost is integration plus a security review; the near-term benefit is unblocking security-gated deals and reducing account-takeover risk. Note the residual risk: this is a small open-source dependency, so we should pin the version, review the code, and carry a fallback plan.

To engineering: This release adds a supported extension point — you can override the User2Fa class — so we can adapt persistence to our existing schema and add audit fields without forking the package or carrying a patch set. That was the main blocker for adoption. Recommended next steps: (1) timebox a spike integrating it against our real user model and tenancy model, (2) review the challenge/verify flow, rate limiting, recovery-code storage, and secret encryption, (3) confirm Laravel/PHP version support and maintenance activity, (4) decide enforcement policy (optional vs. role-mandatory vs. admin-enforced) as a product decision, not an implementation detail, and (5) document the exit path in case we outgrow it. Treat v1.0.x as a young but stabilizing API: pin the version and read changelogs before upgrading, since a 1.0.1-era package may still make breaking changes in minor releases.

To security / compliance reviewers: The scope is deliberately narrow — enrollment, verification, and recovery for a second factor — which keeps the audit surface small and reviewable in-house. The new override hook increases flexibility but also means our customized User2Fa becomes our responsibility to review, particularly around secret storage and recovery-code handling. We will validate these before rollout and record the dependency in our software inventory with a reviewed version pin.