Service account password rotation periods
Most standards do not set a number of days for changing a service account's password or key; they ask you to set one and keep to it. PCI DSS is the exception for people, and even PCI DSS leaves system accounts to your own risk analysis.
The periods, by standard
| Clause | What it asks | Period |
|---|---|---|
| ISO/IEC 27001 A.5.17 | a management process for authentication information | no number of days: the period is yours |
| NIST SP 800-53 IA-5 | change or refresh authenticators at an organization-defined period, and change defaults before first use | organization-defined: the period is yours |
| PCI DSS 8.3.9 | a user's password used alone changed at least every 90 days, or access assessed dynamically | 90 days, user accounts, where MFA is not used |
| PCI DSS 8.6.3 | system and application account passwords changed periodically and on suspected compromise | the frequency your targeted risk analysis sets (12.3.1) |
| CIS Controls 5.2 | unique passwords per asset | no change period |
| SOC 2 CC6.1 | identification and authentication requirements defined and managed | no number of days: the period is yours |
By account type
| Account type | Period the checker reads |
|---|---|
| Built-in or vendor default account | the period you set; with PCI DSS ticked, 8.6.3 (your targeted risk analysis) stands behind it |
| Break-glass or emergency account | the period you set; with PCI DSS ticked and MFA not reading yes, the 90 days of 8.3.9 as well |
| AI agent credential | the period you set; with PCI DSS ticked, 8.6.3 (your targeted risk analysis) stands behind it |
| Automation or bot (scheduled jobs, RPA) | the period you set; with PCI DSS ticked, 8.6.3 (your targeted risk analysis) stands behind it |
| Service account | the period you set; with PCI DSS ticked, 8.6.3 (your targeted risk analysis) stands behind it |
| API key or access key | the period you set; with PCI DSS ticked, 8.6.3 (your targeted risk analysis) stands behind it |
| OAuth client or app registration | the period you set; with PCI DSS ticked, 8.6.3 (your targeted risk analysis) stands behind it |
| Device or workload identity | the period you set; with PCI DSS ticked, 8.6.3 (your targeted risk analysis) stands behind it |
| Mailbox or resource account | the period you set; with PCI DSS ticked and MFA not reading yes, the 90 days of 8.3.9 as well |
| Test account | the period you set; with PCI DSS ticked and MFA not reading yes, the 90 days of 8.3.9 as well |
| Shared or generic login | the period you set; with PCI DSS ticked and MFA not reading yes, the 90 days of 8.3.9 as well |
| Administrator or privileged person account | the period you set; with PCI DSS ticked and MFA not reading yes, the 90 days of 8.3.9 as well |
| Contractor or guest | the period you set; with PCI DSS ticked and MFA not reading yes, the 90 days of 8.3.9 as well |
| Person (employee) | the period you set; with PCI DSS ticked and MFA not reading yes, the 90 days of 8.3.9 as well |
The checker reads the last changed column (password last set, key last rotated, secret last changed) against the period you set, default 365 days, and fires finding 6 when it is more than that, or when the export says never. Exactly the period never fires. A credential kept in code or a config file is finding 8 whatever its age.
The clauses, set out
PCI DSS 8.6.3System account passwords protected against misusePasswords or passphrases used by system and application accounts must be protected against misuse so that: they are changed periodically, at the frequency set by the entity's own targeted risk analysis performed per Requirement 12.3.1, and upon suspected or confirmed compromise; and they are built with enough complexity for how often the entity changes them. The guidance lists risk factors to weigh (how securely they are stored, such as in a vault; staff turnover; how many people can reach the factor; whether interactive login is possible; and whether dynamic posture analysis is used) and advises that complexity be stricter where changes are infrequent. Objective under the customized approach: passwords of application and system accounts cannot stay usable indefinitely and are built so that guessing and brute-force attacks fail. Future-dated: treated as a best practice up to 31 March 2025 and mandatory since then.
PCI DSS 8.3.9Single-factor passwords changed every 90 days or dynamic analysisIf user access relies on a password or passphrase alone (any single-factor implementation), one of these must hold: the password or passphrase is replaced no less often than every 90 days; or account security posture is assessed dynamically, with access to resources decided automatically and in real time from that assessment. The guidance notes that dynamic analysis may weigh data points such as device integrity, location, access times and resources requested. Applicability: does not apply to in-scope components where MFA is used; not intended for point-of-sale terminal user accounts that are limited to a single card number per transaction. Customer accounts of service providers are excluded, while accounts used by service provider staff are included. Objective under the customized approach: an undetected compromised password or passphrase cannot be used indefinitely.
NIST SP 800-53 IA-5Authenticator ManagementManage system authenticators by: a. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, service, or device receiving the authenticator; b. Establishing initial authenticator content for any authenticators issued by the organization; c. Ensuring that authenticators have sufficient strength of mechanism for their intended use; d. Establishing and implementing administrative procedures for initial authenticator distribution, for lost or compromised or damaged authenticators, and for revoking authenticators; e. Changing default authenticators prior to first use; f. Changing or refreshing authenticators [Assignment: organization-defined time period by authenticator type] or when [Assignment: organization-defined events] occur; g. Protecting authenticator content from unauthorized disclosure and modification; h. Requiring individuals to take, and having devices implement, specific controls to protect authenticators; and i. Changing authenticators for group or role accounts when membership to those accounts changes.
ISO/IEC 27001 A.5.17Authentication informationA management process is to control how authentication information is allocated and managed, and it includes telling personnel how to handle such information properly. Purpose (stated in ISO/IEC 27002:2022): ensures proper entity authentication and prevents authentication process failures. As an Annex A reference control, it is compared with the controls determined in risk treatment (6.1.3 c) and recorded in the Statement of Applicability as included or excluded, with the justification and implementation status (6.1.3 d); implementation guidance is ISO/IEC 27002:2022 5.17.