Time to rotate service account passwords

“How often should we rotate service account passwords?” sounds like a calendar question. In practice, the harder and more useful questions are: which identities exist, who owns them, what depends on them, and why do they still have manually managed passwords?

A blind 60- or 90-day policy can cause outages without removing the weakness. Teams then add never-expire exceptions because no one knows what will fail. A safer plan eliminates stored passwords where possible and gives each remaining secret a tested rotation process.

First, find the identities and their dependencies

“Service account” can mean an Active Directory user running a Windows service, a cloud application identity, an API client, a database login, or an appliance credential. Treat each as a non-human identity with a lifecycle.

For every identity, record:

• Account name, directory or platform, and authentication type
• Primary owner, backup owner, and business application owner
• Services, hosts, scheduled tasks, scripts, pipelines, and integrations that use it
• Permission scope, group memberships, and whether interactive sign-in is allowed
• Where its password, key, certificate, or token is stored
• Creation date, last credential change, expiration, and last observed use
• Rotation method, maintenance window, validation check, and rollback steps
• Decommission trigger and the system retaining its audit logs

Do not infer dependencies from the account description. Search service configuration, task schedulers, application settings, deployment variables, and secret-store logs. Split identities shared by unrelated workloads; otherwise one rotation or compromise affects them all.

An account without a current owner is already a finding. Assign an owner, disable it after testing if it is unused, or plan its replacement. Your same-day offboarding process should also remove departed staff and vendors from the systems that can retrieve or change machine credentials.

Prefer identities that do not expose a reusable password

The strongest rotation project often ends by removing the password entirely. Use the most platform-native option the workload supports:

1. Managed service identity or cloud role. The platform issues short-lived credentials to the approved workload, so neither an administrator nor a configuration file needs the underlying secret.
2. Workload identity federation. A trusted external workload exchanges its signed identity for short-lived access instead of storing a cloud client secret.
3. Group Managed Service Account (gMSA). For supported Windows and Active Directory workloads, domain controllers manage the account password and authorized hosts retrieve it automatically.
4. Platform-rotated certificate or secret. Some applications can accept overlapping credentials and retrieve the current one from a managed store.
5. Manually rotated password. Keep this only where product support or architecture leaves no safer option.

Microsoft’s workload identity overview distinguishes application and managed identities and describes federation as a way to avoid stored secrets. For on-premises Windows services, Microsoft’s gMSA guidance explains automatic password and service principal name management across authorized servers.

Migration still requires testing. A Windows workload is not automatically a gMSA candidate; the application, service logon, domain prerequisites, and host permissions must support it. Test in a representative environment and monitor the production cutover.

Give each workload the smallest useful identity

Automatic credentials do not correct excessive access. A service should not inherit Domain Admin, tenant-wide application permissions, or a broad database role for convenience. Grant the required actions, then test expected success and denial.

Where supported, block interactive logon for service-only identities and alert on an unexpected method or host. Separate production from test and avoid a shared svc-apps account. Independent identities clarify logs and rotation.

Do not confuse Windows LAPS with service-account management. Windows LAPS protects and rotates a device’s local administrator password; it does not replace a domain identity used by an application.

There is no universal rotation interval

NIST SP 800-53 Rev. 5 calls for authenticator-management procedures and for passwords to be changed or refreshed on organization-defined periods or when organization-defined events occur. That framing matters: the control needs a documented policy appropriate to the authenticator and risk, not a number copied from another environment.

Set the interval from privilege, exposure, vendor limits, audit requirements, storage protections, and automation reliability. A privileged static secret copied across servers needs faster attention than a narrowly scoped credential in a managed vault. If a product cannot rotate safely, record the technical debt instead of silently setting never-expire.

Rotate immediately when evidence changes, including:

• The secret may have appeared in source control, a ticket, chat, logs, or a backup
• Its host, vault, administrator workstation, or deployment system may be compromised
• A person or vendor with access leaves or no longer needs it
• The workload changes owner, environment, or permission scope
• Monitoring shows authentication from an unexpected host or method

Suspected exposure is an incident, not just maintenance. Preserve useful logs, replace the credential, investigate how it escaped, and use an incident first-hour checklist to coordinate evidence and containment.

Rotate without breaking production

Never begin by changing a directory password and waiting to see what stops. Use a dependency-aware runbook:

1. Confirm the identity, every known consumer, the owner, and the expected health check.
2. Review permissions and remove stale consumers before the change.
3. Confirm backups, configuration recovery, a maintenance window, and a named rollback decision-maker.
4. If the platform permits two valid credentials, create and stage the new credential before revoking the old one.
5. Update the managed secret store and each consumer through its supported deployment method. Avoid displaying the value in a terminal transcript or ticket.
6. Restart or reload only the components that require it, then test authentication and the actual business transaction.
7. Watch application, directory, and secret-store logs for failures or use of the old credential.
8. Revoke the old credential after all consumers are confirmed, then document the date, result, and next review.

When dual credentials are not supported, rehearse the order in a test environment and prepare an explicit rollback. A successful service start is not enough; submit a job, move a test file, process a test transaction, or run the application’s real dependency check.

Store the remaining secrets for machines, not humans

Passwords and keys should not live in source code, scripts, documents, tickets, chat, or ordinary configuration repositories. Use a managed secret store with restricted access, encryption, audit logs, and programmatic retrieval. Let the workload fetch secrets at runtime and limit administrators to necessary read or rotation rights.

A team password manager still has an important role for credentials that humans must use. Our shared admin secrets guide covers access, recovery, and audit practices for that case. Machine-to-machine credentials are better delivered directly to the approved workload so people are not routinely copying them.

The durable goal is not “all service passwords changed this quarter.” It is a smaller inventory of non-human identities, each with a real owner, narrow permissions, observable use, a supported credential design, and a rotation procedure that has been tested before an emergency.