Filament Password Rotation Laravel Package

Product Decisions This Supports

• Build vs. buy on credential hygiene. Offload "force password rotation at first login / after an admin reset / on a schedule" to a maintained Filament plugin instead of hand-rolling middleware, a change-password form, and the associated DB columns. This is the core decision the package informs.
• Compliance and security-questionnaire roadmap items. Directly supports the controls behind SOC 2 / ISO 27001-style asks and enterprise security reviews ("how do you enforce password expiry?", "can an admin force a reset?"). Useful when a deal is gated on a security questionnaire.
• Scoping and sequencing. Lets you defer or descope a bespoke "account security" epic and spend that capacity on differentiated work; the cost becomes a dependency line item plus a smoke test, not a sprint.
• Release-cadence signal for maintenance budgeting. v2.1.3 is a backward-compatible patch on the 2.1.x line with a real UX fix (Chrome's saved-password autofill and strong-password generator were overwriting the current-password field on the forced-change form; fixed with a hidden username anchor alongside the existing current-password/new-password tokens, with the eye toggle already provided by Filament's ->revealable()). Patch-level, no migration — treat upgrades as routine maintenance, not a project.
• Vendor hygiene as a risk input. The changelog notes that v2.1.2's tag had already been published to Packagist pointing at a different commit, so the intended fix ships in 2.1.3. PM takeaway: pin versions, read changelogs, and don't assume tag == installed artifact. Small friction, worth a line in the dependency policy.

When to Consider This Package

Adopt when:

• Your admin/user surface is built on Filament panels — this is effectively a hard requirement, since it's a Filament plugin rather than framework-agnostic Laravel middleware.
• You need forced password change at login or on admin demand, enforced at the panel level instead of re-implemented per resource or per form.
• A security policy, auditor, or customer contract requires demonstrable rotation/expiry behaviour.
• You're comfortable with a small community/vendor package on semver patch upgrades, and can absorb the occasional UX regression in the forced-change flow.

Look elsewhere when:

• Your auth surface isn't Filament — custom Blade/Inertia/Livewire outside panels, API-first, or SPA clients. The enforcement point won't cover those, and a partial control is worse than a known gap.
• You're passwordless, passkey-first, or SSO-only. Rotating a password users never type is theatre; spend the effort on MFA and session revocation instead.
• You need enterprise support, SLAs, or a named legal entity to sign a vendor security questionnaire.
• Your compliance regime requires a certified control rather than a code-level implementation.
• Your policy is NIST SP 800-63B-aligned — modern guidance favours length and breach-list checks over forced periodic rotation. In that case mandatory rotation is a policy conflict to resolve before it's a feature to ship.
• Pre-rollout check, learned from this release: the 2.1.3 bug was silent — Chrome overwrote the current-password field, so the flow could appear to work while defeating its own purpose. Smoke-test the forced-change form in a real Chrome profile with saved passwords before you rely on it.

How to Pitch It (Stakeholders)

For executives: "We can satisfy the 'enforced password rotation' expectation that shows up in our security questionnaires with a small, actively maintained plugin rather than three to four weeks of engineering. It's a patch-level dependency with low integration risk, and it keeps our build focused on revenue features. Two caveats worth stating up front: it only covers our Filament admin surface, so it complements rather than replaces MFA and a policy review; and it's community-maintained, so we should treat it as a supported dependency with a named owner, not a set-and-forget."

For engineering: "Filament plugin, installed via Composer. It enforces rotation and renders the forced-change form for us — revealable fields, correct current-password/new-password tokens, and as of 2.1.3 a hidden username anchor so Chrome's autofill and password generator stop clobbering the current-password field. Backward compatible patch; pin the version and diff against the changelog rather than trusting tags (2.1.2's tag and Packagist artifact diverged). Before rollout, walk the forced-change flow in Chrome with a saved password on the account, and confirm the plugin covers every auth surface we expose, not just panels — anything outside Filament needs its own enforcement or an explicit accepted gap."