Product Decisions This Supports
- Compliance-driven roadmap item, not a security best practice. This package lets you enforce a maximum password age for Filament panel users, forcing a reset flow on next login. That maps to a real checkbox in many audit frameworks (ISO 27001 interpretations, PCI-DSS 8.3.9 legacy readings, SOC 2 evidence requests, and a long tail of enterprise security questionnaires), so it's most useful as a procurement unblocker rather than a genuine risk-reduction feature.
- Build vs. buy: buy, but only if the scope stays this narrow. The underlying logic — a
password_changed_at timestamp, a configurable max age, a middleware/guard redirect into a Filament reset flow, and a "don't reuse the last N passwords" check — is maybe 150–300 lines of Laravel you'd otherwise own forever. Paying with a small dependency is a reasonable trade if you accept the maintenance risk of a zero-dependency, zero-star package. Budget a spike to read the source before committing; treat it as a starting point you may fork rather than a vendor relationship.
- Feature scoping decision it forces: who is in scope? Admins only, all panel users, or only users in a specific role/tenant? Expiry policies almost always need to be scoped (service accounts, break-glass accounts, and SSO-backed users must be exempted — SSO users have no password in your system to expire, and forcing them through a local reset is a support-ticket generator).
- Prioritization input: this is a substitute for SSO/MFA investment. If a customer is asking for password rotation, the higher-leverage roadmap answer is usually SSO + MFA + conditional access. Shipping password expiry is cheap and visible; it should be sequenced as a stopgap while the real identity work is scheduled, and you should say so explicitly so it doesn't get logged as "security solved."
- Use cases that justify it: B2B/on-prem deployments sold into regulated buyers, admin/staff back-office panels (Filament's sweet spot) rather than customer-facing apps, and deals where a security questionnaire is the only thing standing between you and signature.
When to Consider This Package
Consider it when all of the following are true:
- You have a named, written requirement — a contract clause, an auditor finding, or a customer questionnaire line item — that says passwords must expire. "It seems more secure" is not a requirement.
- Your app is Laravel + Filament, and the affected users live in a Filament panel where the redirect-to-reset UX actually exists.
- Your user base authenticates with local passwords, not SSO/SAML/OIDC, or you can cleanly exempt SSO users.
- You're comfortable reading and potentially forking the code: zero stars, zero dependents, and no visible maintainer track record means you cannot treat this as a supported vendor dependency. Pin the version, vendor it, and add your own tests around the expiry boundary.
- The requirement is time-boxed — you're buying months, not building a five-year identity platform.
Look elsewhere (or build in-house) when:
- You're following modern guidance rather than a written requirement. NIST SP 800-63B has recommended against forced periodic rotation since 2017 because it drives predictable incrementing (
Summer2024! → Fall2024!) and weakens real security. If your driver is "best practice," the correct answer is breached-password checks, MFA, and length minimums — this package will make you less secure while looking more secure.
- You're multi-tenant or have a large user base. Bulk expiry creates synchronized reset storms, helpdesk spikes, and lockouts. You need grace periods, staged rollouts, and admin visibility into who's about to expire — verify the package supports that or plan to add it.
- You need policy administration in-product. Per-tenant or per-role policy config, audit logging of expiry events, "expiring soon" notifications, and exemption management are typically where these features actually land; a simple global config knob won't satisfy enterprise buyers.
- The identity story is already in motion. If SSO is on the roadmap for this quarter, don't ship a local-password mechanism you'll rip out.
How to Pitch It (Stakeholders)
To executives: "A prospect/auditor is asking for enforced password rotation. We can satisfy that requirement for Filament admin users in roughly a day of integration using a small open-source plugin, instead of a sprint of custom work. It closes a compliance checkbox and unblocks the deal. Important caveat: modern security guidance says forced rotation doesn't meaningfully reduce breach risk — so I'm positioning this as a compliance stopgap, not a security win. The durable answer is SSO and MFA, which I'd like on next quarter's roadmap. I'd also flag that the plugin is unmaintained by any measurable standard, so we should vendor it and own the code."
To engineering: "Thin Filament plugin that adds password-age enforcement — a timestamp column, a configurable max age, and a redirect into the panel's reset flow. Small surface area, but treat it as untrusted: zero stars, zero dependents, no release cadence. Spike it, read the source, fork it into our codebase if the logic is sound, and add tests around the boundary conditions and the SSO-exemption path. Also confirm the exempt-user story before we turn it on — we can't have service accounts or SSO users getting locked into a local reset loop."
What I'd want before greenlighting: (1) the specific requirement being satisfied, in writing; (2) confirmation it can be scoped by role/guard and exempts SSO users; (3) a rough estimate of helpdesk load from reset volume; (4) explicit acknowledgment that SSO/MFA remains the strategic answer and this is a bridge.