Nova Password Rotation Laravel Package

Product Decisions This Supports

• Build vs. buy on forced password rotation. This package is the off-the-shelf implementation of a password-expiry control layered onto Laravel Nova's auth — login interception, a forced-change screen, and rotation policy. It answers a recurring "do we build this ourselves?" question with "no, it's a dependency."
• Compliance-driven roadmap items. If an auditor, security questionnaire, or enterprise contract requires periodic credential rotation for admin/staff accounts, this closes that checkbox without bespoke schema, middleware, and UX work.
• White-labelling and multi-tenant admin experience. v2.3.1 makes the forced-change screen honour nova.brand.colors (injected after app.css, mirroring login, with fallback to Nova's default blue). Relevant if you brand Nova per client — an unbranded password prompt mid-session is a classic source of "is this phishing?" support tickets.
• Dependency maintenance posture. Upstream is treating theming polish as patch-level, backward-compatible work, which keeps the cost of staying current low and tells us they care about end-user-facing auth surfaces, not just the policy engine.
• Where policy lives. The release reinforces that this package owns in-app rotation UX only; MFA, SSO, and identity policy remain an IdP concern. Useful for scoping architecture debates.

When to Consider This Package

Consider adopting when:

• You run Laravel Nova and admin accounts are a meaningful part of your threat model (privileged access, shared back-office, agency-managed tenants).
• A compliance regime — SOC 2, ISO 27001, PCI DSS 8.x, HIPAA — or a customer security review requires periodic password changes.
• You white-label Nova or use a custom theme; v2.3.1's brand-colour fix is directly on point, and CSS injection ordering is the thing to smoke-test.
• You want enforcement at the framework layer (redirect to forced-change screen) rather than a manual ops procedure.

Look elsewhere or deprioritise when:

• You're not on Nova, or you're outside the package's supported Laravel/Nova version range. Packages that reach into Nova internals (Nova::brandColorsCSS()) are most fragile across Nova major upgrades — pin and test accordingly.
• Modern guidance (NIST SP 800-63B, NCSC) discourages forced periodic rotation in favour of length, breach-list checks, and MFA. Rotation may be a compliance ritual rather than a real control; adopt for the checkbox, not for the security story.
• You need org-wide identity policy — push it to Okta/Entra/Keycloak rather than per-app code.
• You need password history, complexity rules, or breach-list integration — verify coverage before assuming; this release says nothing about those.

Adoption criteria: confirm supported Laravel/Nova versions, check release cadence and maintenance signals (small but active), and review test coverage of the auth-critical paths.

How to Pitch It (Stakeholders)

Executives: This is a small, single-purpose add-on for our Nova admin panel that enforces the password-expiry policy auditors and customer security questionnaires ask about. Buying it rather than building removes roughly a sprint of custom auth work plus the ongoing cost of owning a security-sensitive screen. The new v2.3.1 is a patch: backward compatible, no migrations, no API changes. It fixes a cosmetic defect where the forced-password-change screen ignored our brand colours — exactly the low-risk maintenance we want from a dependency. Recommendation: adopt for Nova-based internal tooling where rotation is required, while keeping MFA, SSO, and breach detection at the IdP layer.

Engineering: Patch release, no breaking changes. It injects Nova::brandColorsCSS() after app.css on the forced-change screen so the primary submit button honours nova.brand.colors, falling back to Nova's default blue when unset. Routine version bump; the only thing that moved is CSS cascade ordering, so a quick smoke test of the forced-change flow is worthwhile if you use custom brand colours or a custom Nova theme.