Compliance Alignment Guide

TAC and PCI DSS v4.0

How TAC maps to the Payment Card Industry Data Security Standard requirements for protecting access to cardholder data environments.

Note: This guide describes how TAC’s capabilities align to key PCI-DSS v4.0 requirements. PCI-DSS compliance is assessed by a Qualified Security Assessor (QSA) against your complete control environment.

PCI-DSS v4.0

Control Mapping

TAC addresses access control, authentication, audit, and monitoring requirements for applications within your CDE, and reduces attack surface relevant to security testing — PCI-DSS Requirements 1, 7, 8, 10, and 11.

TAC Scope in PCI-DSS

TAC controls access to applications and systems within the CDE — administrative consoles, operations tools, customer service portals, dashboards, and other applications that interact with cardholder data. TAC addresses access control, authentication, audit, and monitoring requirements (Requirements 1, 7, 8, 10) for systems in scope, and reduces the attack surface that Requirement 11 scans must cover.

TAC does not encrypt PAN at rest, tokenise cardholder data, mediate payment processing, replace network segmentation, or perform vulnerability scans or penetration tests. Requirements such as Req 3 (storage), Req 4 (CHD transmission), Req 5 (anti-malware), and Req 6 (secure development) are satisfied by other controls in your environment.

Network Protection

Requirement 1 — Network Security Controls

Requirement How TAC Delivers
1.2 — Install and maintain network security controls TAC reverse proxy architecture closes all inbound firewall ports except one encrypted channel (TLS 1.2 or TLS 1.3 with FIPS 140-2 compliant cryptographic modules) for the CDE applications it fronts. Administrative consoles, operations tools, and other applications in scope are not directly addressable from the internet.
1.3 — Restrict inbound and outbound traffic to and from the CDE All access traffic to the CDE applications TAC protects flows through the TAC policy engine. Unauthorised connections are blocked before reaching the target application. (Note: TAC complements but does not replace network segmentation between CDE and non-CDE networks.)
1.4 — Prohibit direct public access between the internet and the CDE Stealth infrastructure for protected applications — no TAC-fronted application is directly addressable from the internet. All access must pass through TAC authentication and policy evaluation.
Access Control

Requirement 7 — Restrict Access by Business Need

Requirement How TAC Delivers
7.2.1 — Access control model defined for each system component Least-privilege policy engine restricts each user to only the CDE applications and functions required for their role. Access is explicitly granted — never implicit.
7.2.2 — Access assigned based on job classification and function Unified policy engine maintains per-application, per-user access policies with full audit history of policy changes. Role-based and attribute-based access control supported.
7.2.4 — Application and system accounts (service accounts, AI agents) Non-human identities — service accounts, API clients, and AI agents accessing CDE applications — governed by the same identity, policy, and audit framework as human users. No separate identity silo for programmatic access.
7.3 — Access control system enforces access decisions Identity federation connects to all directory sources. Every user is governed by the same policy engine regardless of identity source — Active Directory, LDAP, SAML, RADIUS, OIDC, SQL, custom.
Authentication

Requirement 8 — Identify Users and Authenticate Access

Requirement How TAC Delivers
8.2.1 — All users assigned a unique ID TAC identity federation ensures every user is uniquely identified against authoritative directory sources before access is granted.
8.3 — Strong authentication established and managed MFA mandatory for all access to CDE applications — including legacy payment-related applications that cannot natively support modern authentication. Built-in MFA includes FIDO2 / WebAuthn (phishing-resistant), SafeLogin (proprietary), TOTP, push notifications, SMS, OTP, and hardware tokens. Third-party MFA integration with virtually any provider including Duo, RSA, Swivel, biometric solutions, and others. All MFA methods included in base licence — no add-on purchase required.
8.4 — MFA implemented to secure access to the CDE MFA enforced on every access request to TAC-protected CDE applications, not just at login. Per-request policy evaluation ensures authentication remains valid throughout the session.
8.5 — MFA systems prevent misuse and bypass Administrative access to TAC-protected CDE applications requires MFA enforcement at the TAC proxy layer. No mechanism exists to bypass MFA for protected applications.
Service accounts and AI agent authentication Programmatic identities are authenticated and policy-evaluated on every request, just like human users. Service-account credentials and AI-agent identities are first-class citizens in the same policy framework. No separate authentication path for non-human access to protected CDE applications.
Continuous device posture as authentication context Device posture validation extends authentication beyond just ‘who you are’ to ‘what device you are using’ — checking OS version, patch level, antivirus status, disk encryption, firewall status, and domain join status. Non-compliant devices are denied access in real time on every request, not just at login. If device compliance lapses mid-session, access is revoked immediately.
8.2.4 / 8.2.5 — Real-time access revocation Real-time access revocation when user status changes. No need to wait for next login cycle — policy changes take effect immediately on the next request.
Audit Logging

Requirement 10 — Log and Monitor All Access

Requirement How TAC Delivers
10.2 — Audit logs capture all access to system components Every access request to every CDE application TAC fronts — successful or denied — is logged with full attribution and policy decision. Logs include user identity, authentication method, device posture status, source IP and geolocation, timestamp, application accessed, and session duration. Both human users and non-human (service account, AI agent) access are logged.
10.3 — Audit log files protected from unauthorised modification Tamper-evident, centralised logging with full identity attribution for all access events.
10.5.1 — Retain audit logs for at least 12 months TAC audit logs support configurable retention policies meeting PCI-DSS 12-month minimum requirements, with at least three months immediately available for analysis.
10.4 / 10.7 — Review logs and respond to suspicious activity Failed authentications, policy violations, and device compliance failures are logged in real time. TAC provides native real-time monitoring and alerting on these events for the applications it protects. Logs also export to your SIEM via syslog or API for downstream correlation and forensic analysis.
Security Testing

Requirement 11 — Test Security of Systems and Networks

TAC does not perform vulnerability scans or penetration testing. Requirement 11.3 (quarterly internal and external scans) and Requirement 11.4 (penetration testing) still apply to all systems in scope. TAC’s contribution is reducing the attack surface that those scans must cover.

Requirement How TAC Delivers
11.3.1 / 11.3.2 — Internal and external vulnerability scans TAC does not replace the quarterly scan requirement. By closing all inbound ports except one encrypted channel for TAC-fronted applications, the external attack surface presented to scans is reduced to the TAC entry point itself. Internal scans of CDE systems behind TAC still apply per PCI-DSS scope rules.
11.5 — Change-detection mechanisms TAC’s audit logs detect changes to access policies, identity-source bindings, and authentication configuration. (Note: this is change detection on the access control layer, not file integrity monitoring on CDE system files.)
Why TAC for PCI-DSS

Unique Advantages

Four capabilities that make TAC especially effective for controlling access to applications in the CDE.

Close All Ports — Shrink the Access Attack Surface

TAC closes all inbound firewall ports except one encrypted channel (TLS 1.2 or TLS 1.3 with FIPS 140-2 modules) for the CDE applications it fronts. Administrative consoles, ops tools, and customer service portals handling cardholder data are not directly exposed to the internet. Most competing approaches leave datacenter ports open behind their cloud or concentrator — TAC closes them.

Legacy Application Protection

Many payment processing organisations operate critical CDE applications on legacy systems that cannot natively support MFA or modern authentication. TAC injects MFA, device posture, and continuous validation in front of any application — without changing a single line of code or requiring re-certification.

Single-Tenant Isolation

Every TAC deployment is a dedicated, isolated Secure Virtual Appliance — on-premises, in your cloud account, or hybrid. Access policies and audit data for your CDE never co-mingle with another organisation’s environment. Matters where shared-cloud architecture creates QSA or board-level concerns.

All-Inclusive Licensing — No Compliance Gaps

TAC includes every security feature in the base licence: all MFA methods, device posture validation, AI agent governance, SSO, and 24×7 support. No add-on tiers, no per-user MFA surcharges. Eliminates the common PCI risk where organisations skip controls because they are priced as premium add-ons.

PCI-DSS Coverage Summary

TAC Control Coverage at a Glance

PCI-DSS Requirement Topic TAC Coverage
Requirement 1 Network Security Controls Reverse-proxy with single encrypted port for CDE applications; stealth infrastructure for fronted apps
Requirement 7 Restrict Access by Business Need Least-privilege policy engine, role-based access, service accounts & AI agents
Requirement 8 Identify and Authenticate Multi-directory federation, built-in & third-party MFA, device posture, continuous validation
Requirement 10 Log and Monitor Comprehensive attributed audit trail of access to CDE applications, native real-time monitoring, optional SIEM export
Requirement 11 Security Testing Reduces external attack surface scans must cover; does not replace quarterly scan or pentest requirements

Preparing for a PCI-DSS Assessment?

Our team can walk through your specific cardholder data environment and show how TAC addresses each applicable requirement.

Talk to a SpecialistBack to Resources

This website uses cookies

We use cookies to personalize content, provide social media features, and analyze our traffic. We also share information about your use of our site with our analytics partners. You can change your preferences at any time. For more information, please see our Privacy Policy and Cookie Policy. Privacy Policy Cookie Policy