Log In
Sign Up

PCI DSS SSH compliance. Every requirement. Fully mapped.

A complete guide to every SSH-related PCI DSS control — what the auditor requires, what evidence to produce, and how Ezeelogin satisfies each one out of the box.
30-Day Free Trial
Request a Demo

PCI DSS

Security Requirements

01Secure Network
02Firewall Configuration
03Protect Cardholder Data
04Encrypt Data Transmission
05Vulnerability Management
06Secure Systems Update
07Restrict Access Control
08Authenticate Users
09Physical Access Control
10Monitor & Track Access
11Security Testing
12Security Policy

Trusted by hosting companies for

PCI DSS 3.2.1

PCI DSS 4.0

MSPs

Web hosting companies

E-commerce infrastructure

Why SSH is a PCI DSS audit priority

SSH is your biggest privileged access risk — and your auditor knows it

If any of these keep you up at night, Ezeelogin was built specifically to eliminate them.
SSH is the primary method of administrative access to Linux servers. For any organisation that stores, processes, or transmits cardholder data, every SSH connection to an in-scope system is a PCI DSS audit point. PCI DSS does not have a single SSH requirement. SSH access controls are embedded across Requirements 7 (least privilege), 8 (authentication and identity), and 10 (logging and monitoring). Auditors review all three areas when assessing your infrastructure. This page walks through every SSH-related control, what evidence your QSA will ask for, and exactly how to satisfy each requirement — with or without Ezeelogin.

What is in scope for SSH controls?

Any Linux server that stores, processes, or transmits cardholder data — or that is connected to such a system — is in scope. This includes production web servers, database servers, payment processing nodes, and any management infrastructure with access to these systems.

PCI DSS 4.0 — what changed for SSH

PCI DSS 4.0 (effective March 2025) strengthened MFA requirements significantly. MFA is now required for all interactive logins into the CDE — not just remote access. Console access is no longer exempt. All SSH sessions to in-scope systems now require MFA regardless of where the admin is connecting from.

What a QSA will ask for

Current user access list · Session logs for the last 12 months · MFA enforcement proof · Terminated user removal timestamps · Privileged command log · Access review documentation from the last 6 months. Every item on this list is produced automatically by Ezeelogin.

Requirement

Restrict access to system components and cardholder data by business need to know

All access to in-scope systems must be restricted to authorised individuals only, with access rights assigned based on job function. No over-provisioning. No generic or shared credentials for SSH.
Requirement What The Auditor Asks For How
7.2 — Least privilege access
Users granted SSH access only to servers their job role requires. No blanket access to entire fleet.
Current user-to-server access list showing each user's scope. Auditor compares job role against access granted. ✓ EZEELOGIN
7.2.1 — Role-based access control
Access rights assigned by job classification and function, not individual negotiation.
Access policy documentation showing how roles map to server access. Group-based permission structure. ✓ EZEELOGIN
7.2.2 — Third-party / vendor access scoped
External vendors have SSH access only to the servers they manage, not the entire environment.
Vendor access records showing scope. Time-limited access documentation where applicable. ✓ EZEELOGIN
7.2.5 — Access reviewed every 6 months
Formal review of user access list at least once every 6 months, with documented approval or removal decisions.
Date-stamped access review document. Reviewer name. List of users confirmed, modified, or removed. MANUAL
7.3 — Access control system in use
An access control system is implemented and enforces least-privilege restrictions on all system components.
Demonstration of the access control system in operation. Auditor may request a live walk-through. ✓ EZEELOGIN

Ezeelogin satisfies Requirement 7

RBAC and server groups give auditors the least-privilege evidence they need in one export

Request a Demo
User access list, role mapping, and vendor access records — all generated automatically
Requirement 8

Identify users and authenticate access to system components

Every user must have a unique SSH identity. Shared accounts must be attributable to individuals. MFA must be enforced for all non-console administrative access into the cardholder data environment. PCI DSS 4.0 extends this to all interactive logins.
Requirement What The Auditor Asks For How
8.2.1 — Unique user IDs
Every user who connects via SSH has their own unique account. No shared logins between individuals.
User account list showing one account per person. No generic accounts like “admin” or “support” used for direct access. ✓ EZEELOGIN
8.2.2 — Shared account attribution
Where shared system accounts are used, each individual session is attributable to a specific person.
Session recordings showing individual attribution even where a shared OS account is used on the target server. ✓ EZEELOGIN
8.4.2 — MFA for all CDE logins (PCI 4.0)
Multi-factor authentication required for all interactive logins including console access. No exceptions.
Screenshot or live demonstration of MFA enforcement. List of users with MFA enabled. ✓ EZEELOGIN
8.4.3 — MFA for remote admin access
All remote administrative access into the CDE requires MFA regardless of location.
Configuration evidence that MFA is enforced at gateway level before SSH session is established. ✓ EZEELOGIN
8.5.1 — MFA replay attack prevention
MFA systems must prevent replay attacks. TOTP apps and hardware keys satisfy this.
Documentation of MFA method in use. Auditor confirms it is not SMS-based. ✓ EZEELOGIN
8.3.4 — Invalid login lockout
After no more than 10 failed authentication attempts, the account must be locked out.
Configuration showing lockout threshold and duration. ⚠ PARTIAL
8.6.1 — Inactive account disabling
Accounts with no activity for 90 days or more must be disabled.
Report showing last login date per user and disabled inactive accounts. ⚠ PARTIAL
8.3.6 — Terminated user access removed same day
On departure, SSH access must be revoked on the day of termination.
Timestamp showing when access was removed. Auditor may cross-reference HR termination date. ✓ EZEELOGIN

Ezeelogin satisfies Requirement 8

Gateway-level MFA, unique user attribution, and instant revocation — everything Requirement 8 demands

Request a Demo
Supports Google Authenticator, Duo Security, and YubiKey — all PCI DSS 4.0 compliant methods
Requirement 10

Log and monitor all access to system components and cardholder data

All individual access to system components must be logged. Audit trails must be retained for at least 12 months and available for immediate analysis. This is the most evidence-intensive PCI DSS requirement for SSH environments.
Requirement What The Auditor Asks For How
10.2.1 — All access logged
Every SSH session to in-scope servers is logged with user ID, event type, date, time, and originating system.
Sample log entries showing user, server, timestamp, and session duration. Auditor may request a specific date range. ✓ EZEELOGIN
10.2.2 — Privileged actions logged
All actions by users with root or admin privileges must be individually logged and attributable.
Session recordings showing elevated command execution attributable to a named user even where a shared root account was used. ✓ EZEELOGIN
10.2.4 — Failed access attempts logged
All invalid logical access attempts — failed logins, failed MFA — must be captured in audit logs.
Failed authentication log showing user, source IP, timestamp and failure reason. ✓ EZEELOGIN
10.3.2 — Log integrity protected
Audit log files cannot be modified, deleted, or destroyed by standard users.
Demonstration that log access is restricted to admins only. ✓ EZEELOGIN
10.5.1 — 12-month log retention
Audit logs retained for a minimum of 12 months.
Log files dating back 12+ months. Auditor may request logs from specific dates. ⚠ PARTIAL
10.6.1 — NTP synchronisation
All systems use accurate, synchronised time sources for log timestamps.
NTP configuration evidence and timestamp verification. MANUAL
10.7 — SIEM / log forwarding
Logs should be forwarded to a centralised log management system.
SIEM or log server configuration evidence showing SSH logs forwarding. ⚠ PARTIAL
10.4 — Log review process
Documented process exists for reviewing logs.
Written log review policy or procedure with evidence reviews were conducted. MANUAL

Log retention — what to configure in Ezeelogin

Ezeelogin stores session logs on your own infrastructure — no vendor retention limits apply. To satisfy the 12-month requirement: configure sufficient storage on your log partition and set a retention policy that prevents auto-deletion before the 12-month threshold. For long-term archival and immediate SIEM integration, Ezeelogin supports syslog forwarding to Splunk, Elastic (ELK), IBM QRadar, Graylog, and any syslog-compatible system. This satisfies 10.5.1 and 10.7 simultaneously.

Ezeelogin satisfies Requirement 10

Every SSH session recorded, timestamped, replayable — and stored on your own infrastructure

Request a Demo
Syslog forwarding to Splunk, Elastic, QRadar and any syslog-compatible SIEM
Common compliance failures

The SSH gaps auditors find most often — and how to close them

All individual access to system components must be logged. Audit trails must be retained for at least 12 months and available for immediate analysis. This is the most evidence-intensive PCI DSS requirement for SSH environments.

Shared root SSH keys across the team

One key, many people. No individual attribution. Auditors will flag immediately — Requirement 8.2.1 demands unique user IDs traceable to individuals.

Fix — Deploy Ezeelogin as a jump server. All users connect via their own account — individual attribution is maintained even when the target server account is shared root.

No MFA on SSH gateway

Password-only SSH fails Requirement 8.4.2 under PCI DSS 4.0. Auditors now require MFA for all interactive logins — not just remote access from outside the office.

Fix — Enforce MFA at the Ezeelogin gateway level. One configuration applies to all users, all servers. Supports Google Authenticator, Duo, and YubiKey.

No session recordings

Requirement 10 mandates logging of all individual access events. “We have SSH logs” is not sufficient — auditors want to see that privileged actions are attributable to a named user.

Fix — Ezeelogin records every session in full — keystrokes, output, duration, user, server, timestamp. Replayable on demand for audit review.

Departed employees retain access

Requirement 8.3.6 requires same-day termination of access. Without a centralised gateway, SSH key removal across hundreds of servers takes days — and things get missed.

Fix — Ezeelogin's single-action revocation cuts access to every server simultaneously. Timestamped, so you can prove the exact moment access was removed.

Logs stored on the accessed server

If SSH logs are stored on the same server being accessed, a privileged user can modify or delete them. Requirement 10.3.2 requires log integrity protection.

Fix — Ezeelogin stores session logs on the jump server — separate from target servers. Forward to a SIEM for additional integrity and long-term retention.

Access reviews not documented

A verbal review does not satisfy Requirement 7.2.5. The review must be documented — date, reviewer name, and the list of users confirmed or removed.

Fix — Export Ezeelogin's user access report as the review artefact. Add a date and reviewer signature. Done — auditor requirement met.

SSH keys never rotated

Long-lived SSH keys that are never rotated represent a persistent risk. PCI DSS requires periodic review of cryptographic keys and credentials.

Fix — Ezeelogin centralises key management. Rotation can be performed from one interface across all servers simultaneously.

Inconsistent timestamps across systems

Requirement 10.6.1 requires NTP-synchronised timestamps. Log entries from systems with clock drift are inadmissible as reliable evidence in a forensic investigation.

Fix — Configure NTP on all in-scope systems. Ezeelogin's log timestamps are generated at the gateway level — one consistent source. Verify NTP config on target servers separately.

Auditor evidence guide

What your QSA will ask for — and where to find it in Ezeelogin

These are the specific evidence requests that come up in PCI DSS on-site assessments. With Ezeelogin, every item is answerable in minutes.
QSA Evidence Request PCI DSS Requirement Where To Find It In Ezeelogin
Current user access list — who has SSH access to which servers today REQ 7.2 Export User Access Report — shows all users, server groups, last login, and role. One click.
Session logs for the past 12 months — timestamped, user-attributed REQ 10.2.1 Audit Log export — filter by date range, user, or server. Full session history available
immediately.
MFA enforcement proof — all users, no bypass REQ 8.4.2 Show MFA configuration screen. User list showing MFA status per account. Live
demonstration on request.
Terminated user access removal — with timestamp REQ 8.3.6 Access log shows exact timestamp when user was removed and by which admin.
Cross-referenceable with HR termination date.
Session replay of a specific SSH session REQ 10.2.2 Search audit log by user, server, or date. Click any session to replay in full.
Failed login attempt log REQ 10.2.4 Filter audit log to failed authentication events. Export as CSV for audit period.
Access review documentation — last 6 months REQ 7.2.5 Export user access report as review artefact. Add reviewer name, date, and outcome notes.
Log integrity evidence — logs cannot be modified by standard users REQ 10.3.2 Demonstrate non-admin Ezeelogin users cannot access or delete session recordings.
Log retention evidence — 12 months available REQ 10.5.1 Show log files dating back 12+ months on the Ezeelogin server or SIEM.
Auditor may request a specific log.
The cost of non-compliance

What PCI DSS SSH failures actually cost

Non-compliance is not just an audit failure. It carries direct financial and operational consequences.

PCI DSS fines

Card brands can impose fines of $5,000–$100,000 per month for sustained non-compliance. Repeated failures or a confirmed breach can result in permanent revocation of card processing rights.

Impact

Monthly fines: $5,000 – $100,000

Breach liability

If cardholder data is compromised and access controls cannot be demonstrated, liability shifts entirely to you. Average global data breach cost in 2024 was $4.88 million — not including reputational damage.

Impact

Average breach cost: $4.88M (IBM, 2024)

Re-assessment costs

Failing a PCI audit triggers a remediation cycle and additional QSA assessments. Each re-assessment can cost $10,000–$50,000+ in QSA fees alone, plus internal team time.

Impact

Re-assessment cost: $10,000 – $50,000+

Data sovereignty

Self-hosted means your audit logs never leave your environment

For PCI DSS compliance, where your session logs and access records are stored matters. Routing SSH through a SaaS bastion host means your compliance data lives on a third-party cloud — complicating your system boundary and your auditor’s scope.

Ezeelogin runs entirely on your own infrastructure. Session recordings, audit logs, and access data are never sent to a third-party server.
  • System boundary stays clean — your CDE controls are within your infrastructure
  • No third-party data handling— nothing leaves your network boundary
  • Configurable log retention— keep data for as long as your framework requires
  • SIEM-ready— forward logs to Splunk, Elastic, QRadar, or any syslog target
  • No vendor dependency— your access controls don't depend on a SaaS vendor's uptime
Coverage
Ezeelogin PCI Compliance
coverage
PCI DSS SSH Requirements Addressed
8 of 12
SSH-Specific Controls Satisfied Automatically
100%
Supported MFA Methods
TOTP • Duo • YubiKey
SIEM Integrations
Splunk • Elastic • QRadar
Setup Time
30 minutes
Common questions

PCI DSS SSH compliance — questions answered

Ezeelogin satisfies the SSH-specific privileged access controls within PCI DSS — primarily Requirements 7, 8, and 10. PCI DSS compliance covers your entire cardholder data environment, not just SSH access. Ezeelogin eliminates one of the most common audit gaps, but a full programme requires additional controls across your environment. We position Ezeelogin as a control that supports compliance — not as a certified product.
Yes. Ezeelogin produces timestamped, user-attributed session logs with full replay capability. This directly satisfies Requirement 10.2 (audit trail events). The evidence format — exportable logs with user, server, timestamp, and session replay — is consistent with what QSAs request during on-site assessments. Many Ezeelogin customers have used session recordings as primary evidence in PCI audits.
Yes. PCI DSS 4.0 requires MFA for all interactive logins into the CDE — including console access — and prohibits SMS OTP. Ezeelogin enforces MFA at the gateway level using TOTP (Google Authenticator), Duo Security, or YubiKey. All three methods satisfy PCI DSS 4.0’s replay-attack prevention requirement. MFA is enforced before any SSH session can be established — there is no bypass path.
Yes. Ezeelogin supports syslog forwarding to any compatible SIEM — Splunk, Elastic (ELK), IBM QRadar, Graylog, and others. This satisfies Requirement 10.5 (secure audit logs) and 10.7 (log management) when combined with your SIEM’s retention and alerting policies. Session logs can be forwarded in real time for immediate SIEM visibility.
Ezeelogin is a self-hosted tool — it runs on your infrastructure, so it falls within your PCI DSS scope rather than being separately certified. This is actually advantageous: your cardholder data never passes through a third-party system, your audit scope stays within your control, and your QSA reviews your deployment directly rather than relying on a vendor’s certification.
Most teams complete installation in under 30 minutes. Getting in-scope servers onboarded, RBAC configured, and MFA enabled typically takes a further 1–2 hours depending on fleet size. We offer a free screen-share session to get through setup with you — and can walk you through producing the specific audit evidence your QSA will request.
Compliance coverage

PCI DSS is one of eight frameworks Ezeelogin addresses

The same SSH access controls that satisfy PCI DSS also map directly to requirements in ISO 27001, SOC 2, HIPAA, NIST, and more.

PCI-DSS 3.2.1 / 4.0

ISO 27001

SOC 2

HIPAA

NIST

GDPR

SOX

FedRAMP

Start satisfying PCI DSS SSH requirements today

Self-hosted. Up in 30 minutes. 30-day free trial, no credit card required.
30-Day Free Trial
Request a Demo
Trusted by hosting companies managing millions of servers since 2009.