7.3 Access control systems: requirements and evidence

What PCI DSS 7.3 asks an access control system to do

If you are preparing for a PCI DSS assessment, you need to show that access to cardholder data is enforced by technology, not just described in a policy. Requirement 7.3 asks for an access control system that does that enforcement across the environment. The three sub-requirements are 7.3.1, which requires the system to restrict access based on need to know and to cover all system components; 7.3.2, which requires it to enforce permissions assigned to individuals, applications and systems based on job classification and function; and 7.3.3, which requires the system to be set to deny all by default.

Requirements 7.1 and 7.2 cover the policies, roles, approvals and periodic reviews that decide who should have access. Those documents do not stop a misconfigured system from granting access it should not. Requirement 7.3 targets the enforcement layer: the directory, identity provider, single sign-on service, or application authorization settings that actually grant or refuse each request. An assessor will expect the approved model from 7.2 to be visible in the settings of that layer, so the two sections need to match.

The work is usually hard for three reasons. Many systems each have their own user store and permission model, so no single control covers all system components without deliberate design. Local accounts on servers, databases and network devices can bypass the central control entirely. Vendor products often ship with settings that default to allow, so deny-by-default has to be configured and confirmed rather than assumed. To test this requirement, the SSC expects the assessor to examine vendor documentation and the configuration settings of the access control system. Start by collecting that documentation for every system in scope and exporting the actual settings, so you can show the assessor what the system is configured to do today. The official PCI DSS standard page and the SAQ D for service providers list the exact testing steps, and you should confirm the current wording against them.

Which systems, accounts and third parties fall under 7.3

Requirement 7.3 applies to the access control system and to everything it governs, so the scope question is less about which servers hold card data and more about every path that can grant access to them. The cards below cover the decisions that most often expand or shrink the work, and each one names what to check before the assessment starts.

Every component in or connected to the CDE

The access control system must cover all system components, so the inventory is the starting point. Servers, databases, network devices, cloud consoles, admin tools and applications that can reach card data all need to sit behind the central control. Any component left out is a gap an assessor will test for. Check the asset inventory against the data flow diagram and confirm that connected systems are covered, not only systems that store card data. Expect this to be the largest single driver of effort in 7.3.

Local and shared accounts

Local accounts on servers, network devices and appliances can bypass the central control entirely. Shared or generic administrator accounts create the same problem because the access cannot be tied to one person or one job function. Identify every local and shared account on in-scope components, decide whether it can be removed or moved under central management, and document the exceptions. Each account you cannot retire becomes a question about how its access is restricted.

Applications that delegate sign-in

Applications that sign users in through a central identity provider inherit that provider's access rules, but only if sign-in actually goes through it. Applications with their own user tables, or with a local fallback login, sit outside the control unless those paths are disabled or governed. Map each in-scope application to its sign-in method and confirm where role and permission decisions are made. Open-source identity providers such as authentik and Keycloak can act as this central point, and the integration work is usually where scope surprises appear.

The access control system itself

The requirement covers the access control system, so its own administrator accounts, configuration files and change history are in scope. A compromised identity provider admin account can grant access to every system behind it. Inventory who can change policies, group memberships and provider settings, confirm those accounts are controlled under the same rules, and keep configuration exports that an assessor can review. Vendor documentation and configuration settings are what the assessor will examine.

Directory sync and provisioning paths

Accounts often reach the access control system through directory synchronization or automated provisioning. Each of these paths is a route to permissions, so each one needs to be understood and in scope. Document which systems create, change and remove accounts, what rules map roles to access, and how orphaned accounts are caught. Tools such as midPoint or LDAP-based federation can automate this, but only if their inbound and outbound rules are reviewed and documented as part of the scope.

Third-party and managed service access

Vendors, managed service providers and support staff who connect into the environment bring their own accounts and remote access tools. Their access is in scope whether or not their people are on your payroll. List every third party with a path into the CDE, identify whether they use your central control or their own credentials, and confirm that their access is enabled only when needed and restricted to their job function. Ask providers for their own access documentation early, because it determines how much of their environment you must rely on.

How an assessor tests 7.3 and what passes

This table compares each part of Requirement 7.3 with what the assessor usually examines, the evidence they typically request and the findings that come up most often. Assessors base their testing on vendor documentation and the configuration of the access control system, so the evidence should come from that system rather than from policy statements. The assessor reaches their own conclusion, and this table describes what they usually ask for, not a guaranteed result.

Requirement	What the assessor examines	Evidence usually requested	Common findings
7.3.1 Need-to-know restriction and coverage	Whether the access control system restricts access by need to know and whether it is applied to every system component in the cardholder data environment, including databases, network devices, cloud consoles and admin interfaces	Configuration exports from the access control system, a list of in-scope components showing which authenticate through it, and vendor documentation describing how it enforces restrictions	A component in scope that authenticates against a local account store outside the central system, or a console left out of the policy
7.3.2 Permissions by job classification and function	Whether permissions assigned to individuals, applications and system accounts match their job classification and function, using role-to-permission mappings	Role-to-permission mapping exports, group membership reports and a sample of user assignments with the job role each person holds	Roles that grant more than the job function requires, shared roles covering unrelated duties, or service accounts with broad rights
7.3.3 Deny all by default	Whether the default policy of the access control system denies access when no rule applies, and whether exceptions are explicit	Default policy settings or configuration files, a sample of exception rules with approvals, and a test showing a request with no matching rule is refused	A default allow setting, a catch-all rule that grants broad access, or a default that was changed during an upgrade and never reviewed
Coverage across system components	Whether every system component in the cardholder data environment is enforced by the access control system, and whether the component inventory matches the system's configuration	Current component inventory mapped to the access control system, integration settings for each component, and a reconciliation between the two	Components added after the last review that were never connected, or components that accept local logins alongside central sign-in
Negative testing of restricted accounts	Whether a restricted account is actually denied access to resources outside its role	Dated samples from test accounts showing denied attempts, along with the log entries recording those denials	Denials that cannot be reproduced, or logs that show a denial without the account and resource identified

How to implement 7.3 in sequence

This sequence turns Requirement 7.3 into a working central access control system with a documented inventory, a role model, a default-deny baseline, and test evidence that an assessor can examine.

Inventory every system component that needs enforcement
Start from your cardholder data environment boundary and list every system component in it, including servers, databases, network devices, cloud accounts, administrative consoles, applications and service accounts. Record the owner and the access path for each one. The output is a component inventory that the access control system must cover, because 7.3.1 applies to all system components, not only the applications your team likes. The step is done when the inventory reconciles with your network and data-flow diagrams and an unexplained component cannot be found.
Choose or confirm the central access control system
Decide which platform will act as the single enforcement point for sign-in and authorization, or confirm the platform already in use. Candidates include identity providers such as authentik, FreeIPA for Linux and UNIX environments, and Keycloak with directory federation, with midPoint as an option for provisioning across connected systems. Confirm with each vendor or project which protocols and integrations it supports for your inventory, since not every system will accept every method. The output is a written decision record naming the system, its role in enforcement, and the components it does not yet reach.
Define the role model by job classification and function
Work with business owners to define roles that match job classification and function, such as payment operations, customer support, database administration and application support. Keep roles tied to need to know and avoid building one role per person. The output is a role catalog with a description, an owner and an approver for each role, which will carry the permissions required by 7.3.2.
Set the default-deny policy and confirm it in configuration
Configure the central system so that access is denied unless a rule explicitly grants it. Apply the same baseline to every connected application and directory group, and remove any default allow rules inherited from installation. Export the relevant configuration settings and store them under change control. The output is a configuration export and a short note showing where the deny-by-default setting lives for each enforcement point, which is the evidence an assessor will examine for 7.3.3.
Map each role to the permissions its job function requires
For each role in the catalog, list the specific permissions it needs on each component, and remove anything the job does not require. Check that privileged permissions are assigned to narrow roles and that no role grants broader access than its description. The output is a role-permission map that ties every permission to a job function and an approver. This map is what you will compare against actual assignments during testing.
Connect applications and directories to the central system
Integrate each application, directory and infrastructure component so that sign-in and permissions flow from the central system. For applications, this usually means delegating sign-in through OAuth2, OpenID Connect, SAML, LDAP or a proxy provider. For directories, it means federating or synchronizing accounts from the corporate directory. Where accounts must exist on target systems, define inbound and outbound provisioning rules so role changes propagate. The output is an integration list showing each component, its method and its owner, with any component still using local accounts flagged.
Close or document exceptions with a named owner
Identify components that cannot yet be enforced by the central system, such as legacy hosts, appliances with local accounts or vendor-managed consoles. Either bring them under the central system or record a documented exception with a business justification, a compensating measure, an owner and a review point. Confirm with your assessor how they expect exceptions to be handled before you rely on any of them. The output is an exception register that shows each open gap and its closure plan.
Test that denial works and retain the results
Test from the perspective of users in each role. Confirm that users receive the permissions in the role-permission map, that out-of-scope requests are denied, and that a new account with no assignments cannot reach protected components. Repeat the checks after configuration changes. Retain the test scripts, the results and any remediation records. The output is a dated test record that matches the configuration export and role map, so the evidence for 7.3.1 to 7.3.3 can be shown in one place. Ask your assessor which testing format they will accept.

Evidence that satisfies 7.3 and how to keep it current

An assessor testing 7.3 examines how the access control system is configured and what it actually did, so the evidence has to show both the settings and the operating record. The cards below cover six artifacts, how often each one should be refreshed between assessments, and who in your organization should own it. Confirm the exact format and sampling with your QSA before you start collecting.

Default-deny configuration exports

Export the access control system's configuration showing that every policy, rule or group defaults to deny, with explicit grants only. Capture the settings for each enforcement point, not just the primary console, and keep the export with the date and the account that produced it. Check that no permissive catch-all rule or inherited wildcard overrides the deny default. Refresh after every configuration change and at least quarterly. Owner: the security engineering team that administers the platform.

Cardholder data environment component coverage list

Map every system component in the cardholder data environment inventory to the access control system that governs it, including servers, databases, network devices, cloud consoles and administrative jump hosts. Any component without an identified enforcement point is a gap the assessor will find. Reconcile this list against the inventory each time the environment changes. A component with no access control entry is a finding. Owner: the compliance lead, with platform engineering supplying the data.

Role-to-permission mapping with approvals

Document which job classifications and functions receive which permissions in the access control system, and keep the approval record for each role definition and for each change to it. Assessors compare these mappings with job descriptions and the access reviews from Requirement 7.2 to confirm that permissions follow job function. Remove roles that no longer match a documented function. Every role needs a named approver and a review date. Owner: the business data owner for each role, with IAM administration maintaining the record.

Identity provider and directory integration settings

Record how applications delegate sign-in to the identity provider, and how that provider receives accounts from the corporate directory, such as LDAP or Active Directory user federation. Export the federation mappings, sync schedules and the provisioning rules that create, change and remove accounts. Confirm that a removed directory account also loses access to connected applications. Re-export after any change to a federation, provider or sync rule. Owner: directory services, with the security team reviewing the settings.

Denied access attempt samples

Collect logs of access requests the system rejected, and sample them to show that the deny default works in practice. Denials for accounts outside the documented roles are the strongest proof. Retain the log source, the time range and the query used to pull the sample, so the assessor can reproduce it. Ask your QSA how many samples and which period they expect. Pull a fresh sample each quarter, not only before the assessment. Owner: the security operations team, with the access control administrators reviewing the results.

Change records for permission updates

Keep a ticket or change record for every grant, modification and removal of permissions in the access control system, with the requester, the approver, the justification and the completion date. Compare a sample of these records against the live configuration to confirm that the system matches what was approved. Unapproved changes found in this comparison are the issue assessors most often raise. Each change record must link to an approval before the change is applied. Owner: the IAM team, with the change advisory board approving high-impact changes.

What meeting 7.3 costs in money and effort

This table compares each cost component of meeting Requirement 7.3, who is paid for it, whether it is one-time or recurring, what pushes it up and how to contain it. Use it to frame a written quote, since no supplied figures set prices or durations for these components. The main takeaway is that open-source identity platforms usually remove license spend, but configuration, integration and evidence upkeep remain and drive most of the effort.

Cost component	One-time or recurring	What drives it up	How to keep it down
Access control or identity tooling licenses	Recurring if commercial; none for open-source licenses	Per-user or per-system licensing, premium modules for federation or provisioning, support contracts	Choose open-source platforms such as authentik, FreeIPA, Keycloak or midPoint, then confirm which features your version needs and whether paid support is required
Engineering time to configure and integrate	One-time, with periodic rework after upgrades	Number of applications, legacy systems without modern protocols, custom connectors, number of system components in scope	Inventory every system component first, standardize on a few sign-in protocols, and ask the implementation partner to quote per integration in writing
Role design and approval effort	One-time build, then recurring as roles change	Number of job functions, unclear job classifications, individual exceptions, absence of an owner for each role	Map roles to job classification and function before configuring, limit exceptions, and assign one approver per role
Identity synchronization and provisioning	One-time build, recurring operation	Number of authoritative sources, multiple directories, complex inbound and outbound rules, reconciliation failures	Name one authoritative source, document the rules, and confirm how the platform handles reconciliation and discovery
Evidence upkeep	Recurring	Manual exports of configuration, unclear ownership of screenshots, changes made outside change control, evidence needed for each assessment period	Keep configuration under version control, schedule automated exports, and agree the evidence list with the QSA before the assessment period opens
External review or penetration testing of the access control configuration	Recurring, usually once per assessment cycle or after major change	Size of the access control estate, number of integrations, depth of test agreed in scope	Ask for a fixed scope in writing, test after changes rather than on a fixed schedule alone, and reuse results across assessments
Assessor time for sampling	Recurring, tied to each assessment	Number of systems the QSA samples, missing or inconsistent configuration records, unresolved findings from prior cycles	Prepare configuration exports and deny-by-default settings per system in advance, and ask the QSA to quantify expected sampling effort in a written quote

Who does what: your team, a partner and the assessor

Your organization owns the access control system and every decision it enforces. Your security, identity and business owners decide which job functions exist, which systems each function may reach, and what "deny all by default" means for your environment. The access control system is only as accurate as the role model behind it, so this design work stays with you even when a partner builds the technical components.

Access design and role decisions: defining job classifications, the permissions each one receives and the systems they cover across all system components.
Approvals: signing off on the default-deny policy, exceptions and changes to role assignments before they go live.
Owned evidence: keeping the configuration exports, change records, approval tickets and review outputs that show the system behaves as designed.
Ongoing operation: administering the system after handover, including onboarding, offboarding and role changes.
Vendor documentation: retaining the product documentation the assessor will examine for each access control component.

Before engaging anyone, confirm that a named owner can explain each role and approve each exception without outside help.

Open-source platforms that can produce 7.3 evidence

Several self-hosted open-source platforms can serve as the access control system that Requirement 7.3 describes, but none of them satisfies 7.3 by being installed. The assessor tests the configured behavior: which identities can reach which systems, whether permissions follow job function, and whether the default is deny. authentik (MIT) fits the application side of this picture. It acts as an identity provider, and applications delegate sign-in to it through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers. Each application that is onboarded to authentik should be listed in the access control inventory, and the team should confirm that applications not yet onboarded cannot be reached without a grant.

FreeIPA (GPL-3.0-or-later) addresses the Linux and UNIX side. It provides single sign-on across those environments through an MIT Kerberos KDC, so host access can be tied to central identities instead of local accounts. For a cardholder data environment, the practical decision is which hosts and services are enrolled and which group-based access rules apply to them. Keycloak (Apache-2.0) is the other common pattern: its user federation connects to existing LDAP or Active Directory servers and synchronizes users into Keycloak, so accounts managed in the corporate directory are the ones used for application sign-in. Where the directory is the system of record, the assessor will want to see that Keycloak does not create a parallel set of accounts with broader rights.

midPoint (EUPL-1.2+) covers the lifecycle question: who creates, changes and removes access on connected systems when role assignments change. It provisions accounts, keeps them aligned through live synchronization and scheduled reconciliation, and discovers differences using separately defined inbound and outbound rules. Its reconciliation reports are a useful source of evidence that accounts match approved roles. Each tool produces evidence for its own part of the chain, but the organization must still confirm that each configured control meets 7.3 in its own environment, including the vendor documentation and settings the assessor will examine. Licence terms should be reviewed against the organization's own obligations before adoption.

Questions buyers ask about 7.3 before hiring help

How much effort does PCI DSS requirement 7.3 take to meet?

The effort depends mostly on how many systems the access control system must cover and how many separate sources of accounts and permissions exist. Requirement 7.3 asks that an access control system cover all system components in scope, enforce permissions by job classification and function, and deny all access by default. Effort rises when systems have local accounts, separate application logins or several directories that must be reconciled. It falls when one central identity source already feeds most systems. Costs come in two parts: internal staff time to map roles and test configurations, and any partner fees for design and configuration work. Ask a partner for a written quote that lists the systems in scope, the identity sources to integrate, the roles to define, and the evidence to be delivered. No price is implied by this answer.

What sets the timeline for 7.3 access control work?

The timeline is set by the number of components in scope, the state of existing role definitions, and how many integrations the access control system needs. Work that starts from clean, documented job functions moves faster than work that first requires an agreed role model. Dependencies also matter: directory clean-up, change windows on production systems, and sign-off from the assessor's expected testing approach can add time. Requirement 7.3 is typically tested by examining vendor documentation and the configuration of the access control system, so teams should plan time to export and retain those settings. Ask for a timeline in the written scope that names each phase, the systems in each phase, and the owner who approves each milestone.

What does our staff need to provide for 7.3 work?

Your staff must supply decisions that no partner can make for you. Those include the job classifications and functions that map to access, the owners of each system and identity source, and the approvers for granting and revoking access. Engineers will need administrative access to the systems in scope, change approval for production configuration, and time to test that default-deny behavior blocks unapproved access. Compliance staff should confirm which evidence the assessor expects and where it will be stored. Before a quote is signed, ask the provider to list each internal role and time commitment it depends on, so budgets and project plans reflect the true staffing need.

Can a small team meet 7.3 without an outside partner?

A small team can meet requirement 7.3 without a partner if it has the engineering skills to configure its access control systems, the time to document them, and a clear owner for role decisions. The harder parts are usually consistency across many systems, testing default-deny behavior properly, and keeping configuration evidence current after changes. Teams that choose to do the work internally should confirm the approach with their qualified security assessor early, since the assessor decides whether the evidence is sufficient. A partner can cover design, configuration, testing and documentation under a fixed scope, while your team keeps ownership of the controls and approvals. Compare both options against the same written list of systems and deliverables.

Do open-source access control tools remove the need for a commercial product?

Open-source tools do not automatically remove the need for a commercial product. Whether they fit depends on which systems must be covered and whether each one can delegate sign-in and enforce permissions the way requirement 7.3 expects. authentik, FreeIPA, Keycloak and midPoint each address different parts of the problem: applications signing in through standard protocols, Linux and UNIX single sign-on, federation with existing directories, and automated account provisioning. Some environments will still need vendor-supported products for specific platforms. Confirm capability and licensing for your environment before deciding, and check the terms of each project. Your assessor will examine the configuration and vendor documentation, so document what each tool does and where its settings live.

How does a partner's role differ from the QSA's on 7.3?

The organization owns its controls, a partner prepares the systems and evidence, and only the qualified security assessor (QSA) reaches a validation conclusion. A partner may design the access control architecture, configure the systems, integrate identity sources, test default-deny behavior and assemble configuration evidence. The QSA examines that evidence, tests the controls, and documents the result in the Report on Compliance. A partner cannot issue the validation or decide that requirement 7.3 is met. For independence, the same firm should not perform both the remediation design and the assessment where the assessor's rules forbid it. Ask any partner to state in writing which tasks it performs and which the QSA will perform.

How DeployOpen works on this

DeployOpen plans and implements the access control system that enforces 7.3 Access control systems inside your own infrastructure, using self-hosted open-source platforms. We prepare the configuration and evidence an assessor will examine, while your organization owns the control and the independent QSA issues the assessment.

How we scope

Confirm every system component that falls under the access control system, including cardholder data environment systems and connected directories.
Map which identity sources, applications and system accounts must be enforced by job classification and function.
Agree in writing which deny-by-default settings and permission models are in scope before work starts, since engagements are fixed-scope.

How we build

Deploy the chosen open-source identity provider, such as authentik, FreeIPA or Keycloak, inside your cloud account, data center or air-gapped network.
Configure providers so applications delegate sign-in, with permissions tied to job function and the default posture set to deny all.
Connect provisioning and synchronization, using midPoint or directory federation where needed, so account changes follow role assignments.

How we hand over

Test that unlisted users and applications are denied by default and that permissions match the agreed job classification model.
Document vendor configuration settings and screenshots or exports that show the controls as they are set, the evidence the SSC expects an assessor to examine.
Hand over runbooks, configuration baselines and a change record so your team can show the state of 7.3 controls at any review.

How we support

Offer ongoing support, upgrades and continuous testing of the access control system as a retainer, if your team wants that cover after handover.
Re-verify configuration settings after platform upgrades or directory changes, and update the evidence pack to match.
Confirm with your QSA which evidence format they accept, since DeployOpen prepares evidence but does not issue reports or attestations.

7.3 Access control systems