For years we told people to change their password every 90 days, add a capital letter, a number and a symbol, and never write it down. It turns out most of that advice made things worse. People did what people do. Summer2025! became Autumn2025!, and we called it compliance.
In August 2025 NIST published SP 800-63B-4, the latest version of its digital identity guidelines, and it closes the book on a lot of those old habits. It replaces the 2017 revision that most password policies still quote, so if your policy says "aligned to NIST 800-63B", it's worth checking which version you actually mean.
The theme is simple. Stop making life hard for humans, and put the effort into the controls that actually stop attackers: breach checks, rate limiting and strong MFA.
Here's the catch. NIST 800-63B is written for people logging in. It assumes there's a human at the keyboard who can tap a phone, touch a security key or notice a strange prompt. Service accounts don't fit that picture at all.
A service account is the identity an application, scheduled task, backup job or integration uses to talk to other systems. In almost every environment we assess, they share the same story:
Put those together and you have the perfect target: a privileged account with no MFA, a password that never changes, and logins at 3am that raise no eyebrows because that's what it always does.
Attackers know this. In Active Directory, any domain user can request a Kerberos service ticket for an account with a service principal name and crack it offline, a technique known as Kerberoasting. There's no lockout and no failed logon alerts, because the guessing happens on the attacker's own hardware. A weak, ten-year-old service account password doesn't last long. In the cloud the equivalent is a client secret or API key that never expires, sitting in a repo or a pipeline.
So there's an irony here. "Stop rotating passwords" is good advice for your staff, and dangerous advice if someone applies it to service accounts without the controls that make it safe. NIST's position relies on MFA and breach detection being in place. Service accounts usually have neither.
ASD's Essential Eight is clearer on this point. From Maturity Level Two, credentials for service accounts, local administrator accounts and break glass accounts are expected to be long, unique, unpredictable and managed. In practice that means:
If you do one thing this month, pull a list of every account with "password never expires" set, then check how old those passwords are and which groups the accounts belong to. That list will tell you more about your real exposure than most policy documents.
Then update your password policy to reflect 800-63B-4 for your people, and write a separate standard for non-human identities. They're two different problems and they deserve two different sets of rules.
At Spartans Security our penetration testers find weak or over-privileged service accounts on nearly every internal engagement, and our vCISO team helps organisations put the policy and tooling in place to manage them properly. If you'd like to know how your environment stacks up, get in touch.
.png)