PCI DSS compliance. Meet Requirements 7, 8 & 10. 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.
Trusted by hosting companies for
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. Controls are embedded across Requirements 7 (least privilege), 8 (authentication and identity), and 10 (logging and monitoring) — auditors review all three when assessing your infrastructure.
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 (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.
Current user access list, session logs for the last 12 months, MFA enforcement proof, terminated user removal timestamps, privileged command logs, and access review documentation. Every item is produced automatically by Ezeelogin.
PCI DSS v4.0 Requirement
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 |
| 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 |
| 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 |
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 and Syslog. This satisfies 10.5.1 and 10.7 simultaneously.
Syslog forwarding to Splunk and Syslog
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.
Fix — Enforce MFA at the Ezeelogin gateway level. One configuration applies to all users, all servers. Supports Google Authenticator, Duo, YubiKey. RADIUS and FIDO2.
Fix — Ezeelogin records every session in full — keystrokes, output, duration, user, server, timestamp. Replayable on demand for audit review.
Fix — Ezeelogin's single-action revocation cuts access to every server simultaneously. Timestamped, so you can prove the exact moment access was removed.
Fix — Ezeelogin stores session logs on the jump server — separate from target servers. Forward to a SIEM for additional integrity and long-term retention.
Fix — Export Ezeelogin's user access report as the review artefact. Add a date and reviewer signature. Done — auditor requirement met.
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.
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.
| 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. |
Monthly fines: $5,000 – $100,000
Average breach cost: $4.88M (IBM, 2024)
Re-assessment cost: $10,000 – $50,000+
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, YubiKey, RADIUS, or FIDO2. All these 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 and Syslog. 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.