No Hardcoded Passwords

PCI DSS 4.0.1 Requirement 8.6.2 requires that passwords or passphrases for any application and system accounts that can be used for interactive login are not hardcoded in scripts, configuration/property files, or bespoke/custom source code (PCI DSS v4.0.1 Requirement 8.6.2). Operationalize it by eliminating embedded secrets, moving credentials into approved secret storage, enforcing SDLC scanning and reviews, and retaining evidence that proves secrets cannot be checked in or deployed in code.

Key takeaways:

• Eliminate hardcoded interactive-login credentials from code and config across in-scope environments (PCI DSS v4.0.1 Requirement 8.6.2).
• Replace embedded secrets with centralized secret management plus CI/CD and repository controls that prevent reintroduction.
• Prepare assessor-ready evidence: inventories, scan results, exception handling, and implementation records mapped to in-scope systems.

“No hardcoded passwords” sounds simple until you have to prove it across modern build pipelines, infrastructure-as-code, container images, legacy scripts, and third-party software components. PCI DSS scopes this requirement to passwords/passphrases for application and system accounts that can be used for interactive login, and it explicitly prohibits embedding those credentials in scripts, configuration/property files, or custom source code (PCI DSS v4.0.1 Requirement 8.6.2). That means you need both remediation (remove what exists) and prevention (stop new hardcoding).

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as a control system: define what “hardcoded” means in your environment, identify where interactive logins exist, implement technical guardrails in repositories and CI/CD, and keep evidence that an assessor can independently validate. Your operational goal is not “we told engineers not to do it.” Your goal is “we can demonstrate it doesn’t happen, and we catch it when it does.”

This page gives requirement-level implementation steps, concrete artifacts to retain, and the audit questions that usually surface late if you don’t plan for them early.

Regulatory text

Requirement: “Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code.” (PCI DSS v4.0.1 Requirement 8.6.2)

Operator interpretation (what you must do):

• Prohibit embedded credentials for any account that a human (or process acting like a human) can use to log in interactively (console, SSH, RDP, database client login, admin UI login, etc.).
• Cover multiple locations: scripts, config/property files, and custom source code (PCI DSS v4.0.1 Requirement 8.6.2). In practice, teams also treat container images, IaC templates, and CI/CD variables-as-code as “code/config” because assessors will follow how the environment is built.
• Demonstrate ongoing control: remediation alone is not enough. You need prevention and detection so credentials don’t return in the next release.

Plain-English requirement (what “no hardcoded passwords” means)

A password is “hardcoded” when it is stored directly in a file that is versioned, deployed, or shared as part of your application or system build. Common examples:

• db_password=Winter2026! in an app config file.
• sshpass -p "..." inside a deployment script.
• A test admin password in source code, even if “temporary.”
• A default password baked into a golden image or container layer.

The requirement is specifically about passwords/passphrases for accounts that can be used for interactive login (PCI DSS v4.0.1 Requirement 8.6.2). Treat this as “if the credential would let someone log into something, don’t put it in code or config.”

Who it applies to

Entities: Merchants, service providers, and payment processors handling cardholder data environments (CDE) or connected systems in PCI scope.

Operational contexts where this shows up:

• Application stacks that touch payment pages, tokenization, authorization, settlement, or CDE-adjacent services.
• Shared services used by in-scope systems (identity, secrets, CI/CD runners, logging platforms) because compromise can become a path into the CDE.
• Engineering teams shipping bespoke code, ops teams managing scripts, and platform teams managing configuration/property files and IaC.

Account types to include (minimum practical set):

• OS/system accounts used for admin access (interactive).
• Database accounts used for interactive admin access.
• Application admin accounts for consoles or management UIs.
• Service accounts that have interactive login enabled (even if “normally not used”).

What you actually need to do (step-by-step)

1) Define scope: “interactive login accounts” and “code/config”

Create a short standard that answers two questions:

• What accounts are covered? Any application/system account capable of interactive login (PCI DSS v4.0.1 Requirement 8.6.2).
• What storage locations are forbidden? Scripts, configuration/property files, custom/bespoke source code (PCI DSS v4.0.1 Requirement 8.6.2). Extend your standard to include: container images, IaC templates, and pipeline definitions if they are treated as code in your org.

Deliverable: a one-page control standard engineering can follow.

2) Inventory where hardcoding can exist

Build an inventory of:

• Source code repositories (including “legacy” repos and archived repos still used for builds).
• Configuration repositories (GitOps, Helm charts, Ansible, Terraform, etc.).
• Script locations (build scripts, runbooks-as-code, cron jobs).
• Artifact registries (container registries, AMIs/images if applicable).

If you use Daydream for third-party risk and control tracking, record system ownership and where repositories/config live per in-scope service so you can assign remediation tasks and capture evidence in one place.

3) Detect existing hardcoded passwords

Run targeted discovery:

• Repo scanning for password patterns and high-risk keywords (e.g., password=, passwd, secret=, connection strings).
• Config scanning across deployed environments (the “what’s running” view often differs from Git).
• Image scanning for secrets embedded in container layers or baked files.

Operational note: Expect false positives. Your goal is to create a triage workflow that gets to “confirmed secret” vs “not a secret” quickly, with written disposition.

4) Remediate: remove and replace with approved secret handling

For each confirmed hardcoded interactive-login password:

• Remove it from the file and rotate the credential (assessors will ask whether the old credential still works).
• Replace with a secure retrieval mechanism, typically one of:
  • A secrets manager (cloud native or enterprise vault).
  • Encrypted configuration with runtime decryption controlled by KMS/HSM-backed keys.
  • Environment injection managed by an orchestrator, with access controlled by identity and least privilege.
• Confirm interactive login requirements: if a service account does not need interactive login, disable interactive login where feasible. The requirement targets accounts that can be used for interactive login (PCI DSS v4.0.1 Requirement 8.6.2). Reducing that surface helps.

5) Prevent reintroduction (controls in SDLC and ops)

Implement guardrails that make the secure path the easy path:

• Pre-commit / pre-receive hooks in source control to block likely secrets.
• CI pipeline gates that fail builds on confirmed secrets in code/config.
• Code review checklist requiring reviewers to check for new credentials in diffs.
• Configuration management policy requiring secrets references, not raw values, in property files.
• Exception process for emergency fixes, with time-bound remediation and documented approvals.

6) Prove it works (control testing)

Run periodic control tests:

• Sample repos and config stores for secrets.
• Validate that secret-scanning alerts are reviewed and closed with documented outcomes.
• Confirm that “interactive login” accounts are tracked and that credentials are not embedded.

Required evidence and artifacts to retain

Keep evidence that maps cleanly to “no hardcoded passwords in scripts/config/source code for interactive-login accounts” (PCI DSS v4.0.1 Requirement 8.6.2):

Governance artifacts

• Secure coding/config standard addressing hardcoded passwords (with explicit reference to interactive-login accounts).
• Secret management standard: approved storage locations, access control expectations, rotation triggers.

Technical evidence

• Inventory of in-scope repositories/config stores and owners.
• Secret scanning tool configuration and coverage summary (what repos, what branches, what exclusions, why).
• Scan results with triage records (issue tickets showing findings, disposition, remediation).
• Change records/PR links showing removal of hardcoded passwords.
• Credential rotation evidence after removal (ticket notes, system logs, or IAM change records).

Operational evidence

• CI/CD policy or build logs showing gates that block secrets.
• Exception log (if any), with approvals and closure evidence.

Common exam/audit questions and hangups

Assessors and internal audit typically push on:

• “Show me the repositories and config files for this in-scope application.” If you can’t produce an inventory, you end up scrambling.
• “How do you know developers aren’t committing passwords?” Policy alone rarely satisfies; they will look for technical controls and scan evidence.
• “Does this account allow interactive login?” You need a defensible method to classify accounts and show which are in scope under the requirement language (PCI DSS v4.0.1 Requirement 8.6.2).
• “What about scripts used by ops?” The requirement explicitly names scripts (PCI DSS v4.0.1 Requirement 8.6.2). Ops automation is a frequent gap.

Frequent implementation mistakes (and how to avoid them)

1. Only scanning source code, not configuration/property files. Fix: treat config repos and GitOps repos as first-class scan targets.
2. Ignoring container images and baked artifacts. Fix: scan registries and validate build steps don’t copy secrets into images.
3. Allowing “temporary” hardcoded passwords for testing. Fix: require ephemeral test secrets from secret storage and block commits that contain secrets.
4. No rotation after removal. Fix: make “remove secret” automatically trigger “rotate secret” in the ticket workflow.
5. Overusing allowlists/exclusions. Fix: require justification and periodic review of exclusions; keep evidence that exclusions don’t hide real passwords.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific cases.

From a risk standpoint, hardcoded interactive-login credentials are high impact because they tend to spread: copied into forks, pasted into tickets, cached in build logs, and replicated across environments. They also bypass normal access controls. Treat this as both a PCI compliance requirement and a credential-compromise containment measure.

Practical execution plan (30/60/90)

Because the source pack provides no time-based implementation benchmarks, use phases rather than day counts.

Immediate (stabilize and stop new hardcoding)

• Publish the “no hardcoded passwords” engineering standard aligned to PCI DSS v4.0.1 Requirement 8.6.2.
• Turn on repo scanning for in-scope repos; start with default rules, then tune.
• Implement a basic CI gate for high-confidence secret detections.
• Stand up an exception process for emergency releases.

Near-term (remediate and expand coverage)

• Inventory all code/config/script locations for in-scope systems and assign owners.
• Triage findings and remediate confirmed hardcoded interactive-login passwords; rotate credentials after removal.
• Migrate remaining secrets to an approved secrets manager or encrypted runtime injection.
• Add scanning for config repos, pipelines-as-code, and registry/image artifacts based on how your systems ship.

Ongoing (prove control effectiveness)

• Run periodic sampling and report results to security/compliance leadership.
• Review and prune exclusions/allowlists.
• Validate new repositories and services are onboarded to scanning and secret storage as part of SDLC intake.
• Track coverage and evidence centrally (Daydream can help keep the inventory, issues, and evidence tied to each in-scope system and third party dependency).

Frequently Asked Questions

Does this apply to API keys or tokens, or only passwords?

The cited PCI text is specific to “passwords/passphrases” for application and system accounts used for interactive login (PCI DSS v4.0.1 Requirement 8.6.2). Many teams still treat API keys as secrets and control them similarly, but don’t claim PCI 8.6.2 explicitly covers all secret types unless your assessor agrees in writing.

What if the password is encrypted in the config file?

If the secret is still embedded and deployable from the file, you may still have a hardcoded credential problem in practice. A safer pattern is storing the secret in a secrets manager or encrypting it with keys that are not present in the same repo or deployment path.

Are environment variables considered “hardcoded”?

The requirement names scripts, configuration/property files, and bespoke/custom source code (PCI DSS v4.0.1 Requirement 8.6.2). If env vars are defined in code-repo pipeline files or committed manifests, treat them as “config as code” and control them the same way.

How do we handle break-glass or emergency admin access?

Use a documented exception path that issues temporary credentials from controlled storage, records approvals, and requires post-incident rotation. Avoid embedding any emergency password in a runbook script or config file because scripts are explicitly in scope (PCI DSS v4.0.1 Requirement 8.6.2).

What about third-party software we buy that contains default credentials?

You still need to ensure interactive-login credentials are not embedded in your scripts/config/custom code that deploy or manage it (PCI DSS v4.0.1 Requirement 8.6.2). For the third party product itself, manage defaults through secure installation procedures, contract requirements, and deployment hardening steps.

What evidence is “enough” for an assessor?

Expect to show an inventory of in-scope repos/config stores, scanning coverage and results, tickets/PRs proving removal and rotation, and preventive controls in CI/CD that block reintroduction. Tie evidence to specific in-scope systems so sampling is fast and credible.