8.6 Application and system accounts: PCI DSS evidence

What 8.6 application and system accounts requires and why it fails assessments

Requirement 8.6 asks three things of application and system accounts: interactive login only by exception, no hard-coded passwords in scripts, configuration files or custom source code, and password change frequency and complexity set through a targeted risk analysis. Picture a service account that a nightly batch job has used for years, whose password was typed into a shell script long ago and has never rotated. Under PCI DSS v4.0.1 that account is in scope, and it is the kind of account an assessor will look for first. Sub-requirement 8.6.1 says a system or application account may be used interactively only in exceptional, approved, time-limited cases, and each use must still be tied to a named person. Sub-requirement 8.6.2 bans hard-coded passwords in scripts, configuration files and custom code. Sub-requirement 8.6.3 requires the password change interval and complexity to follow a targeted risk analysis under Requirement 12.3.1, plus a change on suspected compromise.

All three sub-requirements were best practices until 31 March 2025, and they are now required in assessments. Organizations that marked them not applicable during the future-dated period should not assume that carries forward. The risk is concrete. A password written into a repository, a deployment file or a container image is readable by everyone with access to that code, often including former staff, contractors and backup copies that outlive the account. Because the credential is shared and rarely rotated, a single leak gives an attacker a durable foothold, and the logs cannot show which person used it. Confirm with your QSA how they expect the targeted risk analysis to be documented, since the frequency and complexity you choose must be justified in writing.

What usually makes 8.6 hard is not the policy wording but the inventory. Most teams cannot list every system and application account, and many accounts were created by installers or by developers who left years ago. Secrets are also spread across several repositories, CI/CD variables, wiki pages and configuration templates, so a search of one codebase misses the rest. Start by building an account inventory with owners and purposes, then scan repositories and pipeline history for embedded credentials. Open-source scanners such as Semgrep Community Edition and GitLab pipeline secret detection can help find them, but a scanner only reports what it can see, so confirm its coverage against every repository your cardholder data environment depends on. Moving credentials into a secrets manager such as OpenBao is the usual next step, and it should be planned as a migration with rotation and rollback steps, not a one-day change.

Which application and system accounts fall under 8.6

Requirement 8.6 applies to any account that a system or process uses to run without a person at the keyboard. The cards below separate the account types in scope and the scoping questions that decide how much work each one creates, so you can size the inventory before you size the controls.

Database and middleware service accounts

These are the accounts an application uses to open connections to databases, message queues and application servers. They are often created once, shared by several services and never rotated. Under 8.6, each one needs a documented owner, a defined password change approach and no password written into connection strings or config files. Start by listing every connection string in the CDE and the account behind it.

Batch and scheduled job accounts

Cron jobs, scheduled tasks and batch runners often execute under a service account that holds broad rights to move or reconcile card data. Check which jobs touch cardholder data, which run under a shared identity and whether any job is started by a person with an interactive login. Interactive use of these accounts falls under 8.6.1 and needs an exception, an approval and a time limit.

API and integration credentials

API keys, client secrets and tokens used by integrations are service accounts in practice, even when no login screen exists. Scope them by whether they can read, change or export cardholder data, and by whether a vendor or partner holds a copy. Credentials stored in CI variables, scripts or source code are a direct 8.6.2 concern and are usually the fastest finding to confirm.

Accounts that connect applications to each other

Service-to-service identities let one application call another, for example a payment service calling a tokenization or fraud service. Whether these accounts sit inside the CDE or only touch it through a connected system changes the scope of the work. Map each call path that reaches the CDE, record the identity used, and confirm which side stores the secret.

Accounts that reach the cardholder data environment

Whether an account can reach the CDE is the first scoping question and the one that most changes effort. An account that cannot reach the CDE, and cannot read data that flows into it, may fall outside the 8.6 work in your scope document. Confirm this with network and access evidence, not with the account's name, and record the reasoning so an assessor can follow it.

Shared accounts and third-party credentials

An account shared across production and test environments, or one whose password a vendor holds, adds effort in two places. You must show who can use it and prove that a change in one environment does not expose the other. Where a third party holds the credential, confirm in writing how the vendor stores it, how it is rotated and how access is logged, because your assessor will ask for that evidence.

How an assessor tests 8.6.1, 8.6.2 and 8.6.3

This table compares how a QSA samples each Requirement 8.6 sub-requirement, the evidence they ask for and where organizations most often fail. Read each row as a testing sequence: first identify the accounts, then examine what they do, then check how their passwords are managed. The main takeaway is that assessors test against your own account inventory and sampled logs, so an undocumented exception or a hard-coded credential found in code will fail the control regardless of policy wording.

Sub-requirement	Test approach	Evidence requested	Common findings
8.6.1 Interactive use of system and application accounts	Build the list of system and application accounts in the assessed environment, then sample accounts that show interactive login capability and review each against documented approvals.	Account inventory, approval records for each interactive exception, time limits, and login logs tying each interactive session to a named individual.	Service accounts with shell access and no approval, shared interactive logins, and exceptions approved without an expiry date.
8.6.2 No hard-coded passwords	Search scripts, configuration files, container definitions and custom source code for embedded credentials, then check whether any finding is an approved exception or a remediated secret.	Code and configuration search results, secret scanning reports from the pipeline, and the process used to move credentials into a managed store.	Database passwords in deployment scripts, credentials in old commits still reachable in the repository, and secrets in infrastructure-as-code templates.
8.6.3 Password change frequency and complexity	Trace the targeted risk analysis under 12.3.1 that sets the change frequency and complexity for each account type, then sample accounts to confirm passwords were changed on schedule and after suspected compromise.	The targeted risk analysis with its rationale, password change records, rotation logs, and incident records showing changes after suspected compromise.	A risk analysis that sets no frequency, a generic 90-day rule applied without analysis, and passwords that were never rotated after staff or incident events.

The sequence to bring service accounts under 8.6

This sequence moves application and system accounts from undocumented, shared and hard-coded credentials to a documented inventory, controlled interactive access, central secret storage and a risk-based password policy. Each step produces a record that an assessor can trace from the account list to the final exception register.

Build a complete inventory of accounts
Start by listing every application and system account in the environment that is in scope for the cardholder data environment, including accounts on servers, databases, network devices, cloud services, middleware, monitoring tools and CI/CD systems. For each account, record the owning team, the system it serves, the systems that hold its credentials, and the last password change. Include accounts created by vendors and default accounts that were never removed. Sources usually include directory exports, database user tables, cloud IAM reports and configuration management data. The step is complete when the inventory is reviewed against system owners and any account without an owner has been assigned one or flagged for removal. The output is the account inventory, which becomes the baseline for every later step.
Classify interactive and non-interactive use
For each account in the inventory, determine whether it is used only by automated processes or whether a person can log in with it interactively. Check authentication logs and session records where they exist, and ask system owners whether anyone uses the account by hand for troubleshooting or maintenance. Accounts that support interactive login must be listed separately, because 8.6.1 permits interactive use only in exceptional, approved, time-limited cases with individual accountability. The step closes when every account has a classification and each interactive account has a named owner. The output is the classified inventory with an interactive-use column that feeds the exception register in the final step.
Search for hard-coded credentials
Scan source repositories, deployment scripts, build pipelines, configuration files and container images for passwords, keys and tokens written directly into them. Open-source secret detection tools can run this search automatically. For example, GitLab Community Edition pipeline secret detection scans files committed and pushed to a repository inside a CI/CD job and writes results to a gl-secret-detection-report.json artifact, and it is available in every tier. Scanning history as well as current files matters, because a secret removed from a file may still sit in earlier commits. Confirm each tool's coverage for your repositories and file types before relying on it, and review findings manually to remove false positives. The step is complete when the scan has covered every in-scope repository and each finding has a ticket. The output is the scan report and a remediation log.
Move secrets into a central store
Remove each hard-coded credential by moving the secret into a central store and changing the application or script to retrieve it at runtime. Where the platform supports it, prefer dynamic credentials that are generated on request and expire automatically. OpenBao, a Mozilla Public License 2.0 project, stores secrets encrypted in one place, can issue short-lived credentials for systems such as databases, attaches leases that revoke secrets on expiry, and can revoke single secrets or whole credential trees. Confirm that each target system can accept the credential method you choose before you cut over. The step is complete when the application runs without the embedded secret, the old credential is rotated or disabled, and the scan in the previous step returns no finding for that secret. The output is an updated secret store with access policies and a cutover record for each application.
Set the targeted risk analysis for passwords
Under 8.6.3, password change frequency and complexity for application and system accounts are set through a targeted risk analysis performed under 12.3.1, not through a fixed rule chosen in advance. Assemble the team that owns the accounts and the security function, then assess each account group against its exposure, privilege, interactive use and the controls that already protect it, such as vaulting or dynamic credentials. Define the change frequency and complexity for each group, state the reasoning, and specify that a password changes on suspected compromise. Have the analysis approved by the appropriate owner. The step is complete when every account group has a documented frequency and complexity rule traceable to the analysis. The output is the signed targeted risk analysis record, which an assessor will read alongside the inventory.
Document exceptions with approvals and limits
Compile an exception register that lists every account still allowed interactive login, every case where the risk analysis sets a different rule for a group, and every system where a credential cannot yet be removed from code or configuration. Each entry should record the business reason, the named individual accountable for use, the approving manager or risk owner, the approval date, the expiry or review condition and the compensating measures in place. Interactive exceptions must be time-limited, so the register should show when each one ends. Ask your assessor or QSA to confirm the evidence format they expect before you finalize the register. The step is complete when every interactive account and open hard-coded credential appears in the register with an approval. The output is the exception register, which is reviewed on a schedule you define and kept with the inventory and risk analysis.

Evidence that passes 8.6 and how to keep it current

An assessor testing 8.6 wants to see who owns each application and system account, why any interactive login exists, and that no secret sits in code or configuration. The six artifacts below connect those answers, and each one needs a recurring check so the evidence still holds on the day an assessor asks for it.

Account inventory with named owners

Keep a current list of every application and system account in scope, with the system it serves, the named owner, the purpose and whether interactive login is enabled. Assessors use this list to see whether every account falls under 8.6.1 or is simply absent from the review. Reconcile the inventory against directory exports and service configurations at a set cadence, and remove accounts for decommissioned services. Ask the owner to confirm each entry at every review, because an inventory with no owner signature is hard to defend.

Exception register for interactive use

Under 8.6.1, interactive use of a system or application account is allowed only in exceptional, approved, time-limited cases where individual accountability is preserved. The register should record each exception, the approver, the business reason, the named human who used the account and the expiry date. Review expired entries weekly and confirm that each interactive session traces back to one person, not a shared login. An empty register is only credible if access logs show no interactive use.

Secret scan reports from pipelines

Pipeline secret detection on committed and pushed files is the most direct evidence against 8.6.2, which bars hard-coded passwords in scripts, configuration files and custom source code. GitLab Community Edition writes detected secrets to a gl-secret-detection-report.json job artifact in every tier, so retain those artifacts and link them to the merge requests that resolved each finding. Scan on every merge request and on a scheduled pipeline for default branches, and record how each detected secret was rotated and removed.

Code scanning for embedded credentials

Repository scanning complements pipeline checks by catching credentials in code paths that pipelines miss, such as scripts run outside CI and configuration templates. Semgrep Community Edition supports languages including Python, Go, Java, JavaScript and Terraform, and it accepts custom rules for organization-specific credential formats. Run it continuously in CI/CD, keep the rule set under version control, and record the rule version alongside each scan result so an assessor can see what was tested on which date.

Vault policy and lease configuration

A secrets manager gives 8.6.2 and 8.6.3 a technical basis: OpenBao stores secrets encrypted in one place, issues dynamic short-lived credentials for systems such as databases, and attaches leases that revoke secrets on expiry. Export the policy files, auth method settings and lease durations, and keep them in version control with change approvals. Confirm periodically that applications retrieve secrets from the vault instead of configuration files, and that revocation of a whole credential tree works as documented in a test.

Targeted risk analysis tied to 12.3.1

Requirement 8.6.3 lets the organization set password change frequency and complexity through a targeted risk analysis performed under 12.3.1, so the analysis is the document that justifies every interval an assessor will check. It should name the account classes, the threats considered, the chosen change frequency and the complexity rule for each class, with the approver and date. Revisit it when the account inventory changes, when a system is added, or after a compromise, and keep prior versions so the history is visible.

Rotation records after suspected compromise

8.6.3 requires passwords for application and system accounts to change on suspected compromise, so keep a dated record for each event that shows the trigger, the accounts affected, who performed the rotation and the verification step. Link each record to the related incident ticket and to the secret scan finding, if one exists. Test the procedure periodically with a tabletop exercise or a controlled rotation, so the record shows the process works and is not only written down.

Which open-source tools produce 8.6 evidence

OpenBao is an open-source secrets manager under the MPL-2.0 license. It stores secrets encrypted in one place and can issue dynamic, short-lived credentials for systems such as databases. Each credential carries a lease, so access ends automatically on expiry, and operators can revoke a single secret or a whole tree of credentials. This supports 8.6.2 by moving passwords out of scripts and configuration files, and it supports 8.6.3 by replacing long-lived static passwords with credentials that rotate by design. Evidence typically includes the secrets engine configuration, lease and revocation logs, and the access policies that limit which workloads can request which credentials.

Secrets location: Configuration exports and access policies show which application and system credentials are held in OpenBao rather than in code.
Lease records: Lease durations and expiry events show how often credentials are reissued, which an assessor can compare against the rotation frequency set in the targeted risk analysis.
Revocation trail: Logs of single and tree revocations show that compromised or retired credentials were removed, supporting the suspected-compromise trigger in 8.6.3.
Access policies: Policy documents show that interactive use of system accounts is limited to named, approved, time-limited cases under 8.6.1.
Audit logging: Audit device output records which identity requested each secret, supporting individual accountability.

Confirm with the vendor and in your own environment which secrets engines, auth methods and audit devices your deployment supports and how long audit records are retained. The MPL-2.0 license generally permits use, but have counsel confirm obligations if you modify the source.

What meeting 8.6 costs in money and effort

This table compares the main cost components of meeting Requirement 8.6, who is paid for each, whether it is one-time or recurring, what drives it up and how to keep it down. Read it as a checklist for scoping a quote, since no dollar figures or durations are given here. The main takeaway is that the largest recurring costs usually come from keeping secrets rotated and evidence current, not from the software itself.

Cost component	One-time or recurring	What drives it	How to reduce it
Tooling or licenses	Recurring (subscriptions or support contracts), one-time for setup	Choice of secrets manager and scanners, number of environments, support tier. Self-hosted open-source components can remove license spend, but hosting and support remain	Confirm license terms of each open-source component, then price infrastructure and support separately in the quote
Inventory of application and system accounts	One-time, then recurring at each review	Number of applications, service accounts, scripts and pipelines that authenticate, and how many are undocumented	Start from existing identity and CMDB records, and tie each account to an owner and a workload
Targeted risk analysis for password change frequency and complexity	One-time, repeated when workloads or threats change	Number of account types, the analysis method used, and the time needed for stakeholder sign-off	Group accounts into a few classes with shared rotation rules, and document the rationale once per class
Engineering time to remove hard-coded credentials	One-time, with ongoing work on new code	Count of scripts, configuration files and custom source containing embedded passwords, plus test coverage and language diversity	Prioritize repositories by exposure, use secret scanning to size the backlog, and fix the highest-risk items first
Migration of workloads to a central secrets store	One-time per workload, with some recurring changes	Number of applications that must fetch secrets at runtime, the need for code changes, and deployment pipeline complexity	Migrate in waves by application group, and reuse one integration pattern across similar workloads
Exception handling for interactive use of accounts	Recurring	Number of approved exceptions, approval workflow steps, and time-limited access tracking with individual accountability	Limit exceptions by policy, set expiry on every approval, and log each use against a named person
Evidence upkeep from scans, logs and reviews	Recurring	Scan frequency, volume of findings, triage time, and how much evidence the assessor will sample across the year	Automate report generation in CI/CD, store artifacts in one place, and assign owners to findings
External testing or independent review	Recurring, usually annual or after major change	Scope of testing, whether reviewers test rotation and secret handling in practice, and how many systems are in the cardholder data environment	Agree the scope in writing before work starts, and reuse prior results where the environment has not changed
Assessor sampling and validation effort	Recurring, at each assessment	Assessor sample size, quality of documentation, and whether evidence is ready when requested	Ask the assessor which accounts and repositories they will sample, and prepare that evidence in advance

Who owns 8.6, who can help, and where the auditor draws the line

Your organization owns every decision that makes Requirement 8.6 true in practice. That starts with a complete inventory of application and system accounts in the cardholder data environment, including who or what uses each one, where its credentials are stored and which systems depend on it. Your team also decides which accounts may ever be used interactively, approves each exception with a defined time limit and an accountable person, and runs the targeted risk analysis under 12.3.1 that sets password change frequency and complexity. Credential rotation, including rotation after suspected compromise, is performed and recorded by your staff or by tooling your staff operate.

Account inventory: a maintained list of every system and application account in scope, with its owner, purpose and credential location.
Exception decisions: written approvals for any interactive use, stating the reason, the approver, the time limit and how individual accountability is kept.
Risk analysis: the documented analysis that justifies the rotation interval and complexity for each account class.
Rotation records: evidence that scheduled and event-driven changes happened and that old credentials no longer work.
Policy and roles: the procedures and named responsibilities that a QSA will read first.

Before any outside party starts work, check that your team can name the owner of each account and produce the approval record for each exception.

Where organizations usually fall short on 8.6

Requirement 8.6 fails in assessments less often because of missing policy than because of gaps between what teams believe about their service accounts and what the systems actually contain. The cards below cover the places where those gaps usually hide, how to close each one, and the evidence an assessor will ask to see.

Service accounts missing from the inventory

Most application and system accounts are created during deployments, integrations or vendor installs and never recorded in the identity inventory. Assessors start from the directory and the systems, then work backward, so an account nobody listed becomes a finding. Close the gap by pulling account lists from each in-scope database, operating system, middleware platform and cloud tenant, then tagging each account with an owner, purpose and whether it can log in interactively. Evidence is a reconciled account register signed off by the owners, plus the query output used to build it.

Interactive login kept for convenience

Accounts built for automated jobs often allow shell or console logins because someone needed to troubleshoot once and never removed the access. Under 8.6.1, interactive use is allowed only in exceptional, approved, time-limited cases where individual accountability is preserved. Check each service account's login shell and interactive permissions, then disable them by default. Where a person genuinely needs interactive use, require a dated approval, a named individual and a removal date. Evidence is the approval record, the time-bound grant and logs tying each session to a person.

Secrets left in commits and build scripts

Hard-coded passwords persist in old commits, deleted branches, CI variables copied into scripts and configuration files that teams assumed were private. Removing the line from the current file does not satisfy 8.6.2 if the secret remains in history and still works. Run pipeline secret detection across full repository history, not only the latest commit, and check build scripts and configuration templates separately. GitLab Community Edition writes detected secrets to a gl-secret-detection-report.json job artifact, which gives you a record to triage. Evidence is the scan report, the rotation record for each exposed credential and the change that moved the secret into a vault.

Passwords that never change

Many application and system passwords have not changed since the system was installed because no one owns the decision. Under 8.6.3, change frequency and complexity must follow a targeted risk analysis performed under 12.3.1, and passwords must also change on suspected compromise. Without that analysis, the organization has no defensible interval to show an assessor. Document the risk analysis for each account class, state the chosen frequency and complexity with reasons, and confirm that the schedule is enforced. Evidence is the signed targeted risk analysis, the rotation log and the compromise-triggered change records.

Scan results never triaged

Teams often run secret scanning or static analysis, then let the reports pile up without an owner, a severity decision or a closure date. An assessor sees a control that produces findings but shows no evidence that anyone acted on them. Assign triage responsibility, define how each finding is classified as a true positive, false positive or accepted risk, and set a remediation path for real secrets. Semgrep Community Edition can run in CI/CD pipelines to scan repositories continuously, and its results need the same triage discipline. Evidence is the triage log with dispositions, the remediation tickets and the rescan showing the finding is gone.

Questions buyers ask about 8.6 cost, effort and outside help

How much effort does requirement 8.6 take to meet?

The effort depends on how many application and system accounts exist, how many of them currently allow interactive login, and how many scripts, configuration files and repositories hold credentials in plain text. Requirement 8.6 has three parts: restricting interactive use of these accounts, removing hard-coded passwords, and setting password change and complexity rules through a targeted risk analysis. The first step is an inventory, because most organizations discover more accounts and embedded secrets than their documentation suggests. Ask any provider to break its estimate into inventory, secret discovery, remediation, rotation design and evidence collection, so you can see where the time actually goes.

Can an in-house team meet 8.6 without a partner?

Yes, an internal team can meet 8.6 if it has engineers who understand the applications, the platform team can operate a secrets store, and someone owns the targeted risk analysis under requirement 12.3.1. The work is largely engineering and governance rather than specialized licensing, so the main constraint is usually capacity and knowledge of legacy systems. Organizations often bring in outside help for the inventory, for a defined migration sprint, or for an independent review of the rotation design before the assessor arrives. Whatever you decide, the organization remains responsible for its controls, and a partner prepares systems and evidence without issuing any assessment result.

What does 8.6 require from application owners?

Application owners must confirm which accounts their systems use, which services depend on each account, and whether any process needs interactive login. They also need to change code, scripts and deployment pipelines so that credentials are read from a managed source at runtime instead of being written into files. Owners usually schedule rotations around batch windows and maintenance periods, so they must agree on those windows before rotation intervals are set. Ask for a named owner per account in your register, because the assessor will expect traceable accountability for each exception and each credential.

What drives how long a migration takes?

Migration time is driven by the number of accounts, the number of systems that consume each credential, and how much of the code is custom versus vendor-supplied. Accounts shared across many services take longer because every consumer must be updated and tested before the old password is retired. Legacy applications that cannot read secrets at runtime may need code changes, vendor patches or a documented exception, and each of those paths adds work. Ask a provider to explain the schedule in terms of these drivers and to name the dependencies that could delay it, rather than accepting a single headline duration.

Do open-source tools remove the need for paid licenses?

Open-source tools can remove license fees for the core software, but they do not remove the other costs of meeting 8.6. OpenBao (MPL-2.0) can store secrets encrypted in one place and issue short-lived dynamic credentials, while GitLab Community Edition (MIT) pipeline secret detection and Semgrep Community Edition (LGPL-2.1-only) can help find committed secrets. You still pay for infrastructure, high availability, backups, engineering time, support contracts if you want them, and evidence work. Confirm the license terms of each component with its publisher and check that the tool's current edition includes the features your design needs.

What can a partner provide to the QSA, and what can it not?

A partner can prepare the account inventory, system configurations, secret-scanning reports, rotation design, change records and runbooks that show how 8.6 is operated. It can also walk the QSA through the evidence and help the organization respond to questions. A partner cannot perform the assessment, write the Report on Compliance, sign the Attestation of Compliance, or certify that the organization is compliant, because only the QSA issues those. Keep the partner's implementation role separate from the assessor's independent judgment, and agree in the written scope exactly which artifacts the partner will deliver.

How DeployOpen scopes and prepares 8.6 evidence

DeployOpen works on requirement 8.6 as a set of technical controls inside your own environment. We scope which application and system accounts exist, remove interactive use and hard-coded credentials where they are found, and prepare the records an independent assessor will ask to see. The organization owns its controls and the assessor issues the validation.

How we scope

Inventory every application and system account across in-scope servers, databases, pipelines and scripts, with its owner and purpose.
Identify which accounts allow interactive login and document the exception, approval and time limit that would justify each one.
Agree in writing which repositories, configuration files and custom source code are covered by the hard-coded credential review.

How we build

Configure a secrets store such as OpenBao so application credentials are held in one encrypted place with defined access policies.
Add pipeline secret detection, such as GitLab's CI/CD job, to scan committed files and write findings to a report artifact.
Set up code scanning with Semgrep rules in CI/CD to flag hard-coded passwords in custom code, and record how findings are triaged.

How we hand over

Deliver the account inventory, exception register and interactive-use approval records in a format your assessor can sample.
Document the targeted risk analysis behind password change frequency and complexity for application and system accounts, for your review and sign-off.
Provide runbooks for rotating credentials on suspected compromise and for revoking accounts, so your team can operate the controls after handover.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer, which covers changes to accounts and pipelines after go-live.
Ask any provider, including DeployOpen, to confirm in writing which 8.6 evidence is prepared by them and which is issued only by your QSA or the assessment body.