PCI DSS 8.6: Service Accounts and NHIs Guide

Service accounts, application accounts and other non-human identities hold most of the standing access in a cardholder data environment, and until PCI DSS v4 the standard said very little about them. Requirement 8.6 changed that: its three sub-requirements control interactive use of system and application accounts, ban hard-coded passwords in scripts, configuration files and custom code, and require those passwords to be protected and changed on a risk-based schedule. They were best practice until 31 March 2025 and are now assessed in full. This guide covers what each sub-requirement asks, the related requirements in 7.2.5, 8.3 and 10.2, how to implement them across Windows, Linux, cloud and CI/CD, and what assessors examine. It is for identity, platform and compliance teams preparing a Report on Compliance or self-assessment, and goes deeper than the overview in the PCI DSS 4.0 Guide.

Key takeaways

8.6 is a three-part control set. 8.6.1 governs interactive login with system accounts, 8.6.2 bans hard-coded passwords for accounts that can log in interactively, and 8.6.3 requires protection and risk-based rotation for all system and application account passwords.
Interactive use must be the exception. If a service account can be used to log in, the default must be "prevented", with any break-glass use justified, approved, time-limited and attributable to a named person.
Rotation frequency is yours to justify. 8.6.3 does not set a number of days; you choose the frequency in a targeted risk analysis under 12.3.1 and must also rotate on suspected compromise.
Least privilege and periodic review sit in Requirement 7. 7.2.5 limits what system accounts can reach and 7.2.5.1 requires their access to be reviewed, so 8.6 evidence is incomplete without an account inventory that shows owners and privileges.
The cleanest compliance path removes passwords altogether. Managed identities, gMSAs, workload identity federation and vault-issued dynamic credentials make 8.6.2 and much of 8.6.3 easy to evidence.

What it is and who it applies to

PCI DSS v4.0.1, the current version in the PCI Security Standards Council (PCI SSC) document library, applies to every entity that stores, processes or transmits cardholder data or sensitive authentication data, and to any system component that can affect the security of that data. Requirement 8 ("Identify Users and Authenticate Access to System Components") covers both people and the accounts used by systems and applications. Section 8.6 sets the objective that the use of application and system accounts and their authentication factors is strictly managed.

In practice "system and application accounts" means any account that is not tied to a single human for day-to-day work: Windows service accounts and gMSAs, Linux daemon users, database logins used by applications, accounts in payment applications and middleware, API and integration users, scheduled-task and batch accounts, cloud IAM users and roles used by workloads, and the identities used by CI/CD pipelines that deploy into the CDE. These are the non-human identities covered in the Non-Human Identity (NHI) Guide.

Merchants and service providers: 8.6.1 to 8.6.3 apply to both, in the CDE and in connected or security-impacting systems.
Self-assessment: the requirements appear in the SAQs that include Requirement 8 in full (for example SAQ D); always check the current SAQ for your channel.
Dates: PCI DSS v4.0 introduced 8.6.x in 2022 as future-dated requirements, best practice until 31 March 2025 and mandatory in every assessment after that date.

Structure and key requirements

The table summarises each requirement in plain language. Read the full text, testing procedures and guidance column in the standard itself before scoping evidence.

Requirement	What it asks (summary)	Applies to	Frequency
8.6.1	Where system or application accounts can be used for interactive login: interactive use is prevented unless needed for an exceptional circumstance, limited to the time needed, backed by a documented business justification, explicitly approved by management, granted only after the individual's identity is confirmed, and every action is attributable to an individual user	Accounts capable of interactive login	Per use
8.6.2	Passwords or passphrases for application and system accounts that can be used for interactive login are not hard coded in scripts, configuration or property files, or bespoke and custom source code; stored passwords must be protected per 8.3.2	Accounts capable of interactive login	Continuous
8.6.3	Passwords or passphrases for all application and system accounts are protected against misuse: changed periodically at a frequency set by targeted risk analysis and on suspicion or confirmation of compromise, with complexity appropriate to how often they change	All system and application accounts	Defined by 12.3.1 analysis
7.2.5	System and application accounts are assigned the least privileges needed for the system or application to operate, and access is limited to the systems, applications or processes that specifically require it	All system and application accounts	Continuous
7.2.5.1	Access by system and application accounts is reviewed periodically, inappropriate access is addressed, and management acknowledges that access remains appropriate	All system and application accounts	Defined by 12.3.1 analysis
8.2.2	Shared, generic or group accounts are used only when necessary on an exception basis, with individual identity confirmed and actions attributable	Accounts used by more than one person	Per use
8.3.2	Strong cryptography renders authentication factors unreadable in transmission and storage	All authentication factors	Continuous
12.3.1	Targeted risk analysis for requirements that let the entity set a frequency: identify assets, threats, likelihood and impact, justify the frequency, review at least every 12 months	8.6.3, 7.2.5.1 and others	At least annually

Two scope points cause most confusion. First, 8.6.2 is limited to accounts that can be used for interactive login, but an account you have not technically blocked from logging in counts as one that can. Second, 8.6.3 applies to every system and application account password, including those that cannot log in interactively, such as database logins used only by an application tier.

Identity and NHI requirements

Requirement 8.6 is the closest PCI DSS comes to an NHI control family. Each sub-requirement maps to a specific identity engineering decision.

Interactive login (8.6.1)

Windows: assign service accounts to the user rights "Deny log on locally" (SeDenyInteractiveLogonRight) and "Deny log on through Remote Desktop Services" by Group Policy under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment. Microsoft notes the deny right supersedes "Allow log on locally". Group Managed Service Accounts (gMSAs) are designed for services, scheduled tasks and app pools and have their password managed by Windows. See the Group Managed Service Accounts (gMSA) Guide.
Linux and Unix: set the shell to /usr/sbin/nologin, lock the password (passwd -l), restrict AllowUsers or AllowGroups in sshd, and use sudo rules rather than direct login for any emergency use. See the Unix and Linux Privileged Access Guide.
Databases: restrict application logins by source host or network, deny console tools where the platform allows, and separate application logins from DBA accounts.
Cloud: workload roles without console passwords are not interactive in the 8.6.1 sense, but a long-lived access key held by a person can be used from a laptop. Treat human use of a workload credential as interactive use.
Exceptions: route emergency use through a PAM checkout that records the requester, approver, ticket and session, so the six 8.6.1 conditions are evidenced by the tool rather than by memory. See the Break-Glass Account Guide.

Hard-coded passwords (8.6.2)

Hard-coded credentials are MITRE CWE-798, and MITRE ATT&CK tracks their abuse as Credentials In Files (T1552.001) and Code Repositories (T1213.003). For 8.6.2, the places to search are the three the requirement names: scripts (PowerShell, Bash, Python, scheduled tasks, cron jobs, deployment scripts), configuration and property files (web.config, application.properties, .env, wp-config.php, Ansible and Terraform variables), and bespoke source code. Replace each with a runtime lookup from a vault or platform secret store, and keep stored secrets encrypted to satisfy 8.3.2.

Protection and rotation (8.6.3)

Frequency: document it in a 12.3.1 targeted risk analysis per account class (for example: vault-managed database logins rotated every 30 days; legacy middleware accounts every 90 days with compensating monitoring). See the PCI DSS Customised Approach and Targeted Risk Analysis Guide.
Complexity: long, randomly generated values from a vault or gMSA are the simplest way to show complexity appropriate to change frequency.
Compromise: define what triggers an out-of-cycle rotation: a secret scanner hit, a departed administrator who knew the value, a vendor breach, or an incident touching the host.
Non-password factors: 8.6.3 speaks about passwords and passphrases, but API keys, client secrets and SSH keys for the same accounts carry the same risk; most assessors expect the same discipline and 8.3.2 still applies to them as authentication factors.

Implementation steps

Build the inventory. Export service accounts from Active Directory (accounts with servicePrincipalName set, accounts in service OUs, accounts with "password never expires"), local accounts on in-scope hosts, database logins, cloud IAM users and roles, and pipeline identities. Record owner, purpose, systems reached, privilege, credential type and whether interactive login is possible. The Service Account Inventory Template is a starting point.
Classify by credential type. Platform-managed (gMSA, managed identity, IAM role), vault-managed, and static. Static credentials are where 8.6.2 and 8.6.3 findings concentrate.
Block interactive login. Apply deny-logon rights, nologin shells and network restrictions in audit first: check event logs for logon types 2 (interactive) and 10 (remote interactive) by service accounts over 30 days, then enforce on a pilot group and widen. Rollback is removing the account from the deny group.
Scan for hard-coded passwords. Run secret scanning across repositories, file shares that hold scripts, configuration management, container images and CI variables. Turn on push protection so new secrets are blocked at commit; GitHub records each bypass as an alert and an audit log event. See the Git Secret Scanning Guide.
Move secrets to runtime retrieval. Replace embedded values with vault lookups or platform identity. Rotate every credential that was found embedded, because it must be assumed copied.
Automate rotation. Use platform features (gMSA, managed rotation in cloud secret stores, vault database engines) and test each rotation end to end in non-production; a rotation that breaks a payment batch at 2am is the usual reason teams stop rotating.
Right-size privilege (7.2.5). Remove Domain Admin, sysadmin and wildcard cloud permissions from service accounts; grant only the tables, queues and hosts each one uses.
Run the first access review (7.2.5.1) with owners, record decisions and management acknowledgement, then schedule the next at the frequency in your targeted risk analysis.

Evidence and assessment

Assessors combine examination of documentation and configuration, interviews and observation. Prepare the following.

Requirement	Evidence to prepare	What assessors typically test
8.6.1	Inventory flag for interactive capability; GPO or configuration showing deny-logon settings; PAM checkout records with justification, approval and duration	Sample accounts and attempt to confirm interactive login is blocked; trace an exception from request to session log
8.6.2	Secure development and scripting standards banning embedded credentials; secret scanning configuration and results; remediation tickets	Examine a sample of scripts, configuration files and custom code for embedded passwords
8.6.3	Targeted risk analysis with chosen frequencies; rotation logs or vault reports; compromise-triggered rotation procedure	Compare last-changed dates against the documented frequency; interview staff on the compromise procedure
7.2.5 / 7.2.5.1	Privilege matrix per account; review records with management sign-off	Compare granted privileges to documented need; check the review happened at the stated frequency
10.2.1.x	Log configuration showing administrative actions, invalid logon attempts and changes to authentication credentials are captured for these accounts	Examine log samples for service account activity

Useful metrics: percentage of in-scope system accounts with interactive login blocked; count of open hard-coded secret findings and median time to remove; percentage of system account credentials platform- or vault-managed; percentage rotated within their documented frequency; number of interactive exceptions per quarter and how many lacked approval. Alert on service accounts producing interactive or remote interactive logons (Windows event 4624 with logon type 2 or 10) and on credential reads from the vault by unexpected callers.

Mapping to other frameworks

PCI DSS	NIST SP 800-53 Rev 5	NIST CSF 2.0	CIS Controls v8.1	ISO/IEC 27001:2022 Annex A
8.6.1	AC-2 Account Management, AC-2(9) Restrictions on Use of Shared and Group Accounts, IA-4	PR.AA-01	5.5 Establish and maintain an inventory of service accounts	A.5.16 Identity management
8.6.2	IA-5(7) No Embedded Unencrypted Static Authenticators	PR.AA-01	16.1 Secure application development process	A.5.17 Authentication information, A.8.28 Secure coding
8.6.3	IA-5 Authenticator Management, IA-5(1) Password-based Authentication	PR.AA-01	5.2 Use unique passwords	A.5.17 Authentication information
7.2.5 / 7.2.5.1	AC-6 Least Privilege, AC-6(9) Log Use of Privileged Functions	PR.AA-05	6.8 Define and maintain role-based access control	A.8.2 Privileged access rights, A.5.18 Access rights

ATT&CK techniques these controls reduce include Valid Accounts: Local Accounts (T1078.003), Valid Accounts: Cloud Accounts (T1078.004) and Unsecured Credentials: Credentials In Files (T1552.001). For a cross-walk of the whole standard see the PCI DSS 4.0 to ISO 27001 Mapping Guide.

Decision guidance

Platform identity vs vault: where the platform offers it (gMSA, cloud managed identity, workload identity federation), prefer it: there is no password to embed or rotate. Use a vault for third-party software, databases and legacy middleware that need a password. See the Workload Identity Federation Guide.
Remediate vs customised approach: a legacy payment application that can only read a password from a property file may be handled with the customised approach or a compensating control, but expect a QSA to want encryption at rest, file permissions limited to the service, monitoring and an owner-approved retirement plan.
Small merchants: the minimum workable set is an inventory spreadsheet, deny-logon rights, a password manager or cloud secret store for the handful of service passwords, and one documented risk analysis covering rotation frequency.
Large estates: automate discovery and rotation through PAM or secrets tooling, feed the inventory into IGA for 7.2.5.1 reviews, and enforce push protection across all repositories. See the Secrets Management Guide.

Common pitfalls

Inventory limited to Active Directory. Database logins, payment application users and cloud keys are left out, so the assessor finds accounts the entity did not list.
Credentials in configuration on shared storage. In the AI Agent Retail Card Theft Campaign, database credentials in wp-config.php on a shared file system enabled a pivot, and 46 secrets dumped from a cloud secrets manager led to the commerce database and more than 600,000 cards. 8.6.2 and 7.2.5 together address both steps.
Rotation without a risk analysis. Rotating every 90 days out of habit, with no 12.3.1 document, leaves 8.6.3 unevidenced even when the practice is sound.
Scanning only the main branch. Old commits, forks, build logs and container layers still contain the secret; rotate rather than rewrite history and consider it fixed.
Shared admin knowledge of service passwords. If several administrators know a service password, every one of their departures is a compromise trigger under 8.6.3.
Exceptions that never end. A "temporary" interactive exception with no expiry fails the time-limited condition of 8.6.1.

Practitioner checklist

Inventory every system and application account in scope, with owner, purpose, privilege, credential type and interactive capability.
Block interactive and remote interactive login for service accounts, tested in audit first.
Route any interactive exception through a PAM workflow that records justification, approval, duration and the named individual.
Scan scripts, configuration files, custom code, images and CI variables for embedded passwords and enable push protection.
Rotate every credential found embedded and move it to a vault or platform identity.
Write a 12.3.1 targeted risk analysis setting rotation and review frequencies per account class.
Define the triggers for out-of-cycle rotation on suspected compromise.
Remove excess privilege from service accounts and record the review with management acknowledgement.
Log and alert on interactive logons, credential changes and unexpected vault reads by these accounts.

PCI DSS Requirements for Service Accounts and NHIs Guide (8.6): Interactive Use, Hard-Coded Passwords and Reviews