Log Credential and Account Changes

To meet the PCI DSS log credential and account changes requirement, you must configure audit logging so it records every change to identification and authentication credentials, plus all creation, privilege elevation, and admin-account adds/changes/deletes across your cardholder data environment (CDE). Then you must centralize, protect, and routinely review those logs so you can reconstruct who changed access, what changed, and when.

Key takeaways:

• Log every account lifecycle event and every credential/privilege change, especially for administrative access.
• Make logs attributable (unique user), time-synced, centralized, and tamper-resistant so they hold up in an assessment.
• Operationalize with a defined event scope, SIEM/IDP integrations, alerting, and evidence packs tied to change tickets.

“Log Credential and Account Changes” is one of the highest-signal audit logging requirements in PCI DSS because it targets the exact actions attackers and insiders use to gain persistence: creating accounts, elevating privileges, and modifying admin access. PCI DSS does not accept “we log logins” as a substitute. You need logs that capture the change events themselves, and you need them across the systems that actually control access to the CDE: identity providers, directory services, PAM tools, hypervisors, operating systems, databases, applications, and cloud control planes.

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing this requirement is to treat it as an “event coverage” problem with clear ownership: define which systems are in scope, define which change events must be captured, implement logging plus centralization, and build repeatable evidence. Assessors commonly look for gaps around “shadow admin” (local admin accounts, emergency accounts, break-glass access), and around identity systems where account changes happen outside traditional ITSM workflows.

This page gives you requirement-level implementation guidance you can hand to IAM, Security Engineering, and Infrastructure teams, then test quickly with evidence.

Regulatory text

PCI DSS requires that audit logs capture “all changes to identification and authentication credentials,” including “creation of new accounts and elevation of privileges,” and “all changes, additions, or deletions to accounts with administrative access” (PCI DSS v4.0.1 Requirement 10.2.1.5).

Operator interpretation: you must be able to reconstruct every meaningful change to who can access the CDE and how they authenticate. The log record must show at least:

• Who performed the change (a unique user or service identity)
• What changed (account created/modified/deleted, privilege change, credential reset/rotation, admin group membership change)
• When it happened (reliable timestamps)
• Where it happened (system, tenant, host, application, directory)

Plain-English interpretation (what “counts”)

This requirement is about change events, not just successful/failed logins. In practice, your “must log” scope includes:

Credential changes

• Password reset/change (including forced resets)
• MFA enrollment changes (add/remove factor, reset factor)
• API key creation/rotation/revocation
• SSH key add/remove
• Token/certificate issuance and revocation where used for authentication

Account and privilege changes

• New account creation (human and service accounts)
• Account disable/enable and deletion
• Role assignment changes (RBAC)
• Group membership changes that grant access
• Privilege elevation (temporary or permanent)
• Any admin account add/change/delete; any change to admin groups/roles

If a system can grant access to the CDE, changes inside that system must be logged, even if the system is “managed by a third party.”

Who it applies to

Entity types: merchants, service providers, payment processors operating under PCI DSS.

Operational context: any environment that stores, processes, or transmits cardholder data, plus connected systems that provide authentication/authorization into that environment (the practical scope your assessor will probe). Typical in-scope systems include:

• Identity provider (IdP) and MFA platform
• Directory services (e.g., AD/Azure AD/LDAP equivalents)
• Privileged access management (PAM) and vaults
• Cloud IAM control plane (if CDE is in cloud)
• OS-level identity stores (local accounts on servers/appliances)
• Databases and key infrastructure apps that have their own admin users
• Network/security devices with administrative interfaces
• CI/CD or infrastructure-as-code systems that can change access

Account types included: employees, contractors, third-party administrators, service accounts, break-glass/emergency accounts, and application accounts.

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

1) Define the event scope in plain terms

Create an “Account & Credential Change Logging Standard” that lists:

• Systems in scope (CDE systems and access-control systems)
• Events to be logged (credential changes, account lifecycle, privilege/admin changes)
• Minimum fields (actor, target, action, timestamp, system, result)
• Owner for each system’s log configuration and evidence

This document becomes your control’s contract with engineering teams.

2) Inventory where changes can occur (don’t miss side doors)

Run workshops with IAM + Infrastructure + App owners to identify:

• Central IAM changes (IdP, directory)
• Local admin changes on hosts and appliances
• Application-level admin roles (e.g., payment app admin console)
• Cloud role bindings and policies
• “Automation identities” (Terraform/CI runners) that can grant permissions

Common gap: teams document the IdP but miss local accounts and cloud control-plane role assignments.

3) Turn on the right audit sources for each system

For each in-scope system, configure logging so it records the required events. Your technical team should confirm the following, system by system:

• Admin actions and policy changes are captured
• Identity events include actor and target identifiers
• Logs include a stable timestamp and time zone or UTC
• Log retention and export are enabled (not just local viewing)

If the platform only provides partial logs (common with some SaaS tools), document compensating coverage (for example, audit events from the IdP plus admin console audit logs).

4) Centralize logs and protect integrity

Route audit events to a centralized log platform (SIEM or log management) with:

• Restricted access (least privilege for viewing and admin)
• Tamper-resistance controls (append-only or controlled deletion, with auditing of log admin activity)
• Time synchronization across sources so timelines match

This is where many PCI assessments get stuck: logs exist, but they are scattered across consoles with no consistent retention or access controls.

5) Create detections and alerting for the riskiest events

At minimum, implement alerts for:

• New admin account creation
• Admin group membership changes
• Privilege elevation events
• MFA factor resets for privileged users
• Creation of long-lived credentials (API keys, access keys) for privileged roles

Keep the alert list short and high-signal. If alert fatigue causes teams to disable rules, you lose operational value and make evidence harder.

6) Tie changes back to authorized requests

Operationalize a linkage between:

• Change ticket / access request (ITSM or GRC workflow)
• The log event confirming the change occurred
• The approval record (manager/system owner)

You do not need every change to originate from ITSM, but for privileged/admin changes, assessors commonly expect a traceable authorization path.

7) Test the control with “tabletop + proof”

Run a short test cycle:

• Create a test user, reset password/MFA, elevate privileges, add to admin group, then remove
• Confirm every event appears in central logging with correct actor/target/timestamps
• Export evidence (screenshots or log exports) and store in your PCI evidence repository

If your org uses Daydream to run PCI control operations, treat this control as a “repeatable evidence pack”: map each required event type to a saved query, a sample log excerpt, and the owning system.

Required evidence and artifacts to retain

Keep evidence that proves both configuration and operation:

Governance / scope

• System inventory for CDE and access-control systems (with owners)
• Account & Credential Change Logging Standard (event list + minimum fields)

Technical configuration evidence

• Screenshots or exports showing audit logging enabled for each in-scope system
• Log forwarding configuration to the central platform (collector/agent/config)
• Access control proof for log platform (roles/groups, admin list)

Operational evidence

• Sample log records for each event type (new account, privilege elevation, admin add/change/delete, credential changes)
• Saved SIEM queries/dashboards demonstrating retrieval by timeframe, actor, and target
• Alert rules and a small set of alert samples (sanitized)
• One or more change records mapped to corresponding log events for privileged access changes

Common exam/audit questions and hangups

Assessors and internal auditors tend to push on the same issues:

• “Show me logs for an admin privilege change.” They will ask for a specific example and expect to see actor, target, and timestamp.
• “How do you know local admin accounts are covered?” If you only log IdP events, you may miss local changes.
• “Can log admins delete or alter records?” They will look for separation of duties and auditing of log platform admin actions.
• “Do service accounts and automation identities generate auditable trails?” If Terraform or scripts grant access, the actor must be attributable.
• “How do you ensure time consistency?” Time drift breaks investigations and can undermine credibility of evidence.

Frequent implementation mistakes (and how to avoid them)

1. Logging only authentication attempts, not changes.
   Fix: explicitly test password/MFA resets, account creation, role changes, and admin group membership changes, then confirm events land centrally.

2. Missing admin access changes inside applications.
   Fix: include “systems with independent admin consoles” in your inventory, not just OS/IdP.

3. No unique attribution (shared admin accounts).
   Fix: require named admin identities where possible; where shared accounts exist (break-glass), add compensating controls and stronger monitoring.

4. Central logging exists, but nobody can retrieve the right event quickly.
   Fix: build saved queries by event category (admin changes, credential changes) and store them as part of the evidence pack.

5. Log access is too broad.
   Fix: restrict SIEM/log platform access; log all access and administrative actions within the log platform itself.

Enforcement context and risk implications

This requirement is designed to reduce two practical risks:

• Persistence through access changes: attackers often create new accounts, add keys, or elevate roles after initial access. If you don’t log the change, your detection depends on luck.
• Irreversible investigation gaps: during an incident, the first questions are “who changed access?” and “when did privileges change?” Without high-fidelity change logs, you cannot answer confidently, and you may not be able to scope exposure.

Even without public enforcement cases in the provided source catalog, the operational reality is consistent: access-change logging is one of the fastest ways to detect and prove misuse of privileged access.

Practical 30/60/90-day execution plan

First 30 days: Get to a defensible scope and baseline coverage

• Define the in-scope system list for access and admin control into the CDE.
• Publish the event list you will log (credential changes, new accounts, privilege elevation, admin account changes).
• Confirm audit logging is enabled on the highest-risk systems (IdP/directory, PAM, cloud IAM, core CDE hosts).
• Stand up central ingestion for those sources and validate you can retrieve sample events end-to-end.

By 60 days: Make it operational (alerts + evidence)

• Add alerting for admin changes and privilege elevation events in the central platform.
• Restrict log platform access and document separation of duties.
• Build an evidence pack: saved queries, sample events per category, and configuration proof per system.
• Run a controlled test (create user, elevate, reset MFA, modify admin group) and archive outputs.

By 90 days: Close edge cases and harden

• Expand coverage to remaining “side door” systems: local accounts, network/security devices, app admin consoles, CI/CD automation identities.
• Add workflow linkage between access approvals and observed log events for privileged changes.
• Create a recurring review cadence for alerts and a periodic control self-test.
• If you manage multiple environments, standardize a reusable logging baseline via configuration management or templates.

Frequently Asked Questions

Does PCI DSS require logging only for administrators?

No. The requirement explicitly includes all changes to identification and authentication credentials, plus creation of new accounts and privilege elevation, and it specifically calls out admin-account changes as mandatory (PCI DSS v4.0.1 Requirement 10.2.1.5).

Are password resets and MFA resets considered “credential changes”?

Yes. If a reset changes how an identity authenticates, it falls under changes to identification and authentication credentials that must be captured in audit logs (PCI DSS v4.0.1 Requirement 10.2.1.5).

If we use an IdP, do we still need logs from servers and applications?

Often yes. The IdP may not record local admin creation, application-specific admin role changes, or certain system-level privilege changes. Build your scope from “where changes can occur,” not from a single tool.

Do service accounts and automation tools (like CI/CD) need to be included?

Yes. If an automation identity can create accounts, change credentials, or grant privileges, those events must be logged with an attributable actor identity and captured centrally.

What’s the quickest way to produce assessor-ready evidence?

Run a controlled test that triggers each required event type, then export the resulting log entries from your central platform. Pair those with screenshots/exports showing audit logging and forwarding are enabled for each in-scope system.

Where does Daydream fit into this control?

Daydream helps you operationalize the evidence pack: document the in-scope systems and owners, store saved queries and sample events per required category, and track periodic self-tests so you can answer assessor questions without rebuilding evidence each cycle.