Orphaned Account Checker

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

ClauseWhat it asksPeriod
ISO/IEC 27001 A.5.17a management process for authentication informationno number of days: the period is yours
NIST SP 800-53 IA-5change or refresh authenticators at an organization-defined period, and change defaults before first useorganization-defined: the period is yours
PCI DSS 8.3.9a user's password used alone changed at least every 90 days, or access assessed dynamically90 days, user accounts, where MFA is not used
PCI DSS 8.6.3system and application account passwords changed periodically and on suspected compromisethe frequency your targeted risk analysis sets (12.3.1)
CIS Controls 5.2unique passwords per assetno change period
SOC 2 CC6.1identification and authentication requirements defined and managedno number of days: the period is yours

By account type

Account typePeriod the checker reads
Built-in or vendor default accountthe period you set; with PCI DSS ticked, 8.6.3 (your targeted risk analysis) stands behind it
Break-glass or emergency accountthe period you set; with PCI DSS ticked and MFA not reading yes, the 90 days of 8.3.9 as well
AI agent credentialthe 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 accountthe period you set; with PCI DSS ticked, 8.6.3 (your targeted risk analysis) stands behind it
API key or access keythe period you set; with PCI DSS ticked, 8.6.3 (your targeted risk analysis) stands behind it
OAuth client or app registrationthe period you set; with PCI DSS ticked, 8.6.3 (your targeted risk analysis) stands behind it
Device or workload identitythe period you set; with PCI DSS ticked, 8.6.3 (your targeted risk analysis) stands behind it
Mailbox or resource accountthe period you set; with PCI DSS ticked and MFA not reading yes, the 90 days of 8.3.9 as well
Test accountthe period you set; with PCI DSS ticked and MFA not reading yes, the 90 days of 8.3.9 as well
Shared or generic loginthe 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 accountthe period you set; with PCI DSS ticked and MFA not reading yes, the 90 days of 8.3.9 as well
Contractor or guestthe 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 misuse

Passwords 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.

What an auditor asks to see: Targeted risk analysis per 12.3.1 setting change frequency and complexity for service account passwords; Vault rotation logs or change records demonstrating rotation at the defined frequency; Records of rotation after suspected or confirmed compromise; Configuration showing complexity settings for service account credentials
Where account lists usually fall short: Service account passwords unchanged for years because rotation could break applications; Risk analysis sets a long rotation period without raising complexity; No process to rotate credentials when an administrator with knowledge leaves
Source: PCI DSS v4.0
PCI DSS 8.3.9Single-factor passwords changed every 90 days or dynamic analysis

If 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.

What an auditor asks to see: Inventory of in-scope systems using password-only authentication; Maximum password age setting of 90 days or less on those systems; Or configuration and decision logs of the dynamic, risk-based access engine; Documentation of which option applies to each system
Where account lists usually fall short: Password expiry disabled on systems that still rely on passwords alone; Claimed dynamic analysis is only a static conditional access rule; Service provider staff accounts wrongly treated as customer accounts and excluded
Source: PCI DSS v4.0
NIST SP 800-53 IA-5Authenticator Management

Manage 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.

What an auditor asks to see: Identification and authentication policy; System security plan; Addressing authenticator management; System design documentation; System configuration settings and associated documentation; List of system authenticator types; Change control records associated with managing system authenticators; System audit records; Test of Mechanisms supporting and/or implementing authenticator management capability
Where account lists usually fall short: Default authenticators on devices and applications were not changed prior to first use, per e; Authenticators for group or role accounts were not changed when account membership changed, contrary to i
Source: NIST SP 800-53 Rev. 5
ISO/IEC 27001 A.5.17Authentication information

A 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.

What an auditor asks to see: Statement of Applicability entry for control A.5.17, showing inclusion or justified exclusion, implementation status and the risks it treats; Credential issuance procedure requiring identity verification before new, replacement or temporary credentials are provided; Evidence that initial credentials are unique, delivered over protected channels and changed at first use; Password policy and technical configuration showing length, complexity, reuse prevention, breached-password blocking and masked entry; Records of vendor default credentials being changed at installation
Where account lists usually fall short: Initial passwords are sent in clear text email or use a predictable pattern; Default vendor credentials remain on network devices or appliances; Shared account passwords are not changed when someone who knew them leaves; No check against known breached passwords is performed
Source: ISO/IEC 27001:2022 Annex A