Magento admin access for PCI DSS requirement 8

Which requirement 8 controls Magento Open Source helps you meet for admin access

A merchant whose Magento store is in PCI DSS scope has admin users, the servers that run the store and the database behind it, and each of those needs to meet requirement 8. Magento Open Source supports some admin account controls, such as password rules and lockout behavior in the admin configuration, but requirement 8 is an organizational and infrastructure obligation that the platform only partly covers. The rest sits with your identity processes, your servers and database, and the people who access them remotely. The admin-facing sub-requirements are the ones you can configure inside the store. Requirement 8.3.6 sets the password length and complexity rule for passwords used as authentication factors, 8.3.4 covers locking user IDs after repeated invalid attempts, and 8.3.7 covers reuse of recent passwords. Check these against the admin user settings in your installed version, and record what the store actually enforces rather than what the documentation implies. Confirm with your own configuration review whether the admin login and lockout behavior match the stated values in your environment.

Requirements 8.4.1, 8.4.2 and 8.4.3 are where most of the work sits. Requirement 8.4.1 requires multi-factor authentication for non-console administrative access into the cardholder data environment, which includes the admin panel but also SSH and management sessions to the web and database servers. Requirement 8.4.2 extends multi-factor authentication to all access into that environment, and 8.4.3 covers remote network access from outside your network, including vendors and third parties who support the store. None of these are satisfied by a single admin-panel setting. They depend on how your hosting, bastion and VPN access is built, and on which accounts exist outside the store. The decision to make first is the boundary: which systems are in the cardholder data environment, and which accounts can reach them. Build an inventory of admin users, shared or service accounts, server logins and database accounts, and mark which ones fall under 8.4.1 to 8.4.3. Ask your hosting provider or internal platform team to confirm where multi-factor authentication is enforced for each access path before you assume coverage.

Your job as the merchant is to decide what goes into the admin configuration, what goes into infrastructure and what goes into written processes. DeployOpen can prepare the Magento configuration, the server and database access design, and the evidence set, including settings exports, account inventories and access logs. A Qualified Security Assessor or the relevant payment brand decides whether your environment meets requirement 8, and no configuration alone settles that outcome. Treat this as a planning input: ask any implementation partner to show which sub-requirements their work covers, which remain with your team, and what evidence each deliverable produces.

Mapping requirement 8 sub-requirements to Magento admin and infrastructure settings

This table maps the requirement 8 sub-requirements that apply to administrative access to a Magento Open Source store to the Magento settings and infrastructure controls that support them. Read each row as a check to complete for your installed version, because lockout and MFA module settings must be confirmed in Adobe's documentation. The main takeaway is that several controls sit outside Magento, in servers, databases and remote access paths, and each needs its own configuration evidence.

Requirement	Platform capability	Configuration needed
8.3.4: Lock user IDs after no more than 10 invalid attempts, for at least 30 minutes or until identity is confirmed	Magento has admin lockout settings. Confirm the failure threshold and lockout duration for your version in Adobe's admin security documentation.	Set the threshold to 10 or fewer and the lockout to 30 minutes or more. Apply the same rule to SSH, database and hosting console accounts.
8.3.6: Passwords used as authentication factors are at least 12 characters (8 where the system cannot support 12) with numbers and letters	Confirm in Adobe's documentation whether admin password length and character rules can be set for your version.	Set the minimum length to 12 with letters and numbers. Enforce the same length on server, database and vendor accounts.
8.3.7: Do not allow reuse of any of the last four passwords	Confirm whether your version enforces admin password history. If it does not, plan a control at the identity provider or directory.	Require a history of at least four previous passwords on admin, server and database accounts.
8.4.1: Require MFA for all non-console administrative access into the cardholder data environment (CDE)	Magento admin two-factor authentication. Confirm the module, supported providers and enforcement options for your version.	Require MFA for every admin role, plus SSH and database administration sessions that reach the store.
8.4.2: Require MFA for all access into the CDE. Application and system accounts performing automated functions are excluded.	Not a Magento setting. It covers admin, hosting, server and database access together.	Record each automated account with its justification and the controls that limit its use, such as restricted keys and source addresses.
8.4.3: Require MFA for remote network access from outside your network that could affect the CDE, including third parties and vendors	Depends on the VPN, bastion or identity provider in front of Magento, not on Magento itself.	Require MFA for all remote access from outside your network, including vendors, and time-limit vendor accounts.

How password length, lockout and history rules apply to Magento admin accounts

Requirement 8.3.6 sets the password floor for every Magento admin account. Passwords used as authentication factors must be at least 12 characters and contain both numbers and letters. The eight-character alternative applies only where the system cannot support 12, so the first decision is whether your Magento release and the login path in front of it accept a 12-character password. The 12-character rule became mandatory on 31 March 2025, replacing the seven-character minimum from PCI DSS v3.2.1. Any admin password policy still written against the older standard needs updating, and the change should be recorded with the date and the approver.

Requirement 8.3.4 covers lockout. User IDs must be locked after no more than 10 invalid attempts, for at least 30 minutes or until the identity is confirmed. Magento's admin security configuration includes a login failure threshold and a lockout time, but setting names and defaults can change between 2.4.x releases, so confirm them against the version you run. Check that the threshold is 10 or lower and that the lockout duration meets the 30-minute minimum, or that your identity confirmation process applies instead. Then test it with a dedicated test admin account: fail the login to the threshold, confirm the lock, and confirm the unlock behavior after the set time.

Requirement 8.3.7 bars reuse of any of the last four passwords. Magento's password lifetime and forced change settings help with rotation, but they do not confirm that a history of previous passwords is kept or checked. Confirm in your version whether admin password history is retained, how many entries it holds, and whether a reset can reuse an old value. If the platform does not enforce this, decide whether an upstream identity provider will enforce it for admin logins, or whether a documented manual reset procedure will. Test a reset with a reused password to show the result.

Record every gap in the same place as the test results. For each rule, note the Magento version, the setting name and value, the test date, the outcome, and any other control that handles the gap, such as single sign-on enforcing history or the multi-factor controls covered in the sibling admin access sections. If a rule is met through a different method, decide whether it is a defined or customized approach and document the objective it meets. The PCI SSC does not validate compliance itself. Your assessor will check the running system and this record, so screenshots or configuration exports alone are not sufficient evidence.

What evidence proves requirement 8 for your Magento admin

An assessor testing requirement 8 will ask for records, not explanations. The cards below cover the evidence set that shows each Magento administrator is a distinct, authenticated, reviewed and removable identity, and they name who keeps each item current.

Admin user inventory

A current list of every account that can log in to the Magento admin, with the person it belongs to, the role assigned, the date it was created and its status. Each account should map to exactly one named person, with shared or generic logins listed separately so the assessor can see any exceptions. Export the list from the admin user grid or your database on a fixed schedule, and reconcile it against the identity provider and the change tickets that granted access. The store operations lead or the platform owner should own it, with the security team reviewing discrepancies.

MFA enrollment records

Proof that each administrator has enrolled in the two-factor authentication method your organization chose, with the enrollment date and the method type. Magento Open Source supports two-factor authentication through modules, so confirm which provider and version you run and what enrollment data it stores. Keep a dated record for every admin and a list of anyone without enrollment, with the access restriction applied to them. Identity or security administrators should own these records, and the store owner should confirm that no account bypasses the factor.

Password and lockout configuration

Dated exports or screenshots of the settings that enforce minimum length, character mix, password reuse limits and the invalid-attempt lockout. Capture the values against the requirement numbers they support, and record the date and the person who captured them. Requirement 8.3.6 and 8.3.4 are the settings most often questioned, so confirm where your version and any security module store these values before you rely on a screenshot. Each change should create a new capture, and the platform owner should own the configuration baseline.

Access review records

Signed or ticketed reviews showing that someone compared each admin account and its role against current job duties at a defined interval. A useful review lists every account, the reviewer's decision (keep, reduce or remove), the reason for any change and the follow-up ticket. Reviews fail when they only confirm that accounts exist, so ask the reviewer to check role assignments as well. The business owner of the store should sign off, with the security team tracking open actions to closure.

Leaver and vendor removal records

Tickets showing when an employee, contractor or agency account was disabled or deleted, measured against the date access ended. Vendor and agency accounts used for development or support need the same treatment, plus a note of the contract end date and any shared credentials that were rotated. Compare the admin inventory with the HR and vendor lists each month to catch accounts that outlived their owner. The HR or vendor manager should trigger the removal, and the platform team should own the evidence.

Remote access and server logs

Records of administrative access that arrives from outside your network, including VPN, bastion or jump host sessions, and the logs that show which admin accounts authenticated to the store, the database and the servers behind it. Requirements 8.4.1 and 8.4.3 expect these sessions to use multi-factor authentication, so the logs should show the factor used. Confirm with your Magento version and hosting stack which admin login events are written and where, and whether they can be exported with timestamps. The infrastructure team should own retention, and the security team should review samples.

Where multi-factor authentication applies beyond the Magento admin login

Requirement 8.4.1 requires MFA for all non-console administrative access into the cardholder data environment (CDE). Non-console access means an administrative session that reaches a system over the network, from a terminal that is not physically attached to it. For a Magento store, that covers the admin panel and any other administrative session that reaches a CDE system.

Magento admin panel: the admin login is in scope when the store, or the administrative account, sits inside the CDE.
Operating system shells: SSH or remote desktop sessions to web, cache, search or queue nodes that can reach the CDE.
Database administration: SQL clients and administrative consoles that connect to the store database.
Hosting control panels: cloud consoles and provider portals used to change CDE infrastructure.

Check with your QSA which administrative paths sit inside your CDE, since the list above is only a starting point.

What Magento Open Source does not cover for requirement 8

Magento's admin two-factor and password settings apply only to the admin panel. Requirement 8 also reaches the servers, databases, remote paths and shared credentials behind the store, and the decisions for those sit with your team. The six items below are what you must build or decide before an assessor reviews the environment.

MFA for servers, databases and hosting consoles

Requirement 8.4.1 covers non-console administrative access into the CDE, and 8.4.2 extends MFA to all access into the CDE. For a Magento store, that includes SSH to web nodes, database administration, the hosting provider console and the cloud control plane. The Magento admin two-factor setting does not reach any of these paths. Inventory every login path into the hosts and databases behind the store, then confirm each one requires a second factor that is separate from the password.

MFA and access control for vendor and remote access

Requirement 8.4.3 requires MFA for remote network access from outside your network that could access or impact the CDE, including third parties and vendors. Agencies, developers, support partners and extension vendors often connect through VPNs, bastion hosts or remote desktop tools that sit outside the Magento admin. Document each remote path, the named party who uses it, the systems it reaches and the approved access window. Confirm that each vendor account is limited to the environment it needs.

Shared and generic accounts in agencies and integrations

Shared logins for agencies, deployment scripts and administrators make it hard to tie an admin or server action to one person. Integration services such as ERP connectors or payment middleware are a separate case, since 8.4.2 does not apply to application or system accounts performing automated functions. Identify every shared or service credential and decide whether it is a system account or a human login. Replace human shared logins with named accounts, and record who holds each system credential and how it is stored and changed.

Identity lifecycle for joiners and leavers

The MFA and access controls only hold if accounts are created, changed and removed through a defined process. For a Magento store, that process must cover Magento admin users and roles, server and database accounts, SSH keys, hosting console seats and vendor access. Define who approves a new account, which role it receives, how a role change removes earlier access and how a leaver's access is removed from every system. Test the process by sampling recent leavers against each system list.

Scope decision for the cardholder data environment

The systems that need MFA and account controls depend on where the CDE boundary sits. Decide whether the web nodes, database, cache, search, message queue, admin workstations, CI runners and backup systems store, process, transmit or could affect cardholder data. If card data never reaches your servers, document how the payment flow keeps it out and what that means for the remaining systems. Record the decision with a network diagram and data flows, and have your assessor review it before you size the controls.

Assessment by a QSA or an SAQ with an AOC

DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue validation. A Qualified Security Assessor completes a Report on Compliance, or you complete a Self-Assessment Questionnaire, and either produces an Attestation of Compliance. PCI SSC FAQ 1220 states that certificates are not recognized as validation, so a vendor certificate or a partner letter does not replace the AOC. Confirm early which template applies to your store and who signs it.

How to configure admin access before a PCI DSS assessment

This sequence sets up Magento Open Source admin access so that each account, login path and remote connection can be shown to meet requirement 8 before the assessor arrives. The output is a configured admin layer and a dated evidence set that matches the installed release and hosting design.

Confirm the cardholder data environment boundary
Start by mapping the cardholder data environment (CDE) with the people who run the store, the hosting provider and your QSA or internal assessor. List every admin panel, application server, database, cache, search and message service that stores, processes or transmits cardholder data or could affect its security, then record which accounts touch each one. Include vendor accounts for hosting, patching and support. Done means you have a signed boundary diagram and an account-to-system map that the assessor agrees with.
Inventory accounts and retire shared ones
Export the Magento admin user list, then pull accounts from the operating system, database, hosting console, deployment tooling and monitoring. Assign each human account to one named person, and remove or replace any generic or shared login. Check that former staff and contractors have no residual access, including API tokens and integration users. Done means every account has an owner, a purpose and a status, and no shared credential remains in the CDE.
Confirm password and lockout settings for the installed release
Requirement 8.3.6 calls for passwords of at least 12 characters with both numbers and letters, or eight characters only where the system cannot support 12. Requirement 8.3.4 calls for locking the user ID after no more than 10 invalid attempts for at least 30 minutes or until identity is confirmed. Requirement 8.3.7 bars reuse of any of the last four passwords. Review the admin security settings in your installed Magento release and any identity layer you add, then test each rule with a throwaway account. Done means a test log shows each rule enforced.
Choose and test MFA for admin login
Requirement 8.4.1 requires multi-factor authentication for all non-console administrative access into the CDE, and 8.4.2 extends it to all access into the CDE, except application and system accounts performing automated functions. Compare the options Magento supports for your release with your identity provider, and confirm which factor types and recovery paths are available. Test enrollment, login, lost-device recovery and lockout on staging. Done means each admin role signs in with a second factor, and the recovery procedure has been run once.
Apply MFA to remote and vendor access
Requirement 8.4.3 requires multi-factor authentication for all remote network access from outside your network that could access or impact the CDE, including third parties and vendors. List every remote path, such as VPN, bastion host, SSH, database client, hosting console and vendor support tunnel, and enforce a second factor on each one. Remove standing vendor access in favor of time-limited sessions that someone approves. Done means each remote path requires MFA, and a test connection from outside the network fails without the second factor.
Document application and system accounts separately
Application and system accounts, such as cron jobs, integration tokens, service connections to the payment gateway and database replication users, follow different rules from people. Record each one with its owner, the system it serves, its privileges, how its credentials are stored and rotated, and why it is exempt from MFA under 8.4.2 if that applies. Keep this register apart from the personnel account list so the assessor can trace each exemption. Done means the register is complete and each exemption has a written justification.
Collect dated evidence before the assessment
Gather the artifacts an assessor will ask for: the boundary diagram, the account inventory, screenshots or configuration exports for the password and lockout settings, MFA enrollment records, remote access configuration, the application and system account register, and test logs. Date each item and record who produced it. Ask your assessor which evidence format they accept before you package it. Done means every control in this sequence has a dated artifact stored in the assessment folder.

Defined or customized approach for requirement 8 in PCI DSS v4.0.1

A PCI DSS requirement can be met through the defined approach or the customized approach. The defined approach follows the requirement and its testing procedures as written. The customized approach is open only to entities with mature security and risk management, and it meets the stated objective of the requirement in a different way. For Magento Open Source admin access, the choice is made sub-requirement by sub-requirement. A store can use the defined approach for password length and lockout while documenting a customized approach for one control, or for none. Start by assuming the defined approach, because it involves fewer approvals and less documentation.

Only PCI DSS v4.0.1 is active. PCI DSS v4.0 was retired on 31 December 2024, and v3.2.1 was retired on 31 March 2024, so any admin control description still written against v3.2.1 needs updating before the next assessment. The PCI SSC ran a request for comments on v4.0.1 from 3 June to 20 July 2026 to begin the next iteration of the standard. As of October 2026, the SSC had announced no release date for a new version. Plan against v4.0.1, check the SSC website before each assessment cycle, and ask your assessor which version applies to your assessment date.

Most admin password and MFA work belongs in the defined approach. The requirements are specific and testable. Requirement 8.3.6 requires passwords used as authentication factors to be at least 12 characters with both numbers and letters. Requirement 8.3.4 requires user IDs to be locked after no more than 10 invalid attempts, for at least 30 minutes or until identity is confirmed. Requirement 8.3.7 bars reuse of any of the last four passwords. Requirements 8.4.1 and 8.4.2 require MFA for non-console administrative access and for all access into the cardholder data environment. Check each value in the Magento admin security settings and in any external identity provider, record what is on screen at assessment time, and fix any setting that falls short. Application and system accounts that perform automated functions are excluded from 8.4.2, so document them separately.

A customized approach is a different path with heavier paperwork. The entity must document the stated objective of the requirement, perform a risk analysis showing how its alternative meets that objective, and agree the approach with its assessor before relying on it. The assessor then tests the alternative, and the entity must keep evidence of ongoing monitoring. Illustrative only: a team that wants a shared administrator login for maintenance windows would find this hard to justify, because requirement 8 expects accounts that trace to individual people. Raise any customized approach with the assessor early, since an approach agreed late in the cycle can delay the assessment.

The PCI SSC maintains the standard but does not enforce compliance or impose penalties. The individual payment brands decide which entities must comply and validate, and they run any enforcement programs. In practice, your acquirer or the relevant payment brand will ask for evidence, so ask them which validation type applies to your store and what they accept for a customized approach. Validation is documented on PCI SSC templates: a Report on Compliance completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire with an Attestation of Compliance. A certificate alone is not recognized as validation.

What a requirement 8 admin review costs and how long it takes

What drives the effort of a requirement 8 review on Magento Open Source?

The main drivers are the number of admin users, how the store and its supporting servers and databases are hosted, whether you already run an identity provider, how many vendors have remote access, how many extensions and custom modules touch login or admin flows, and the assessment type. Each one adds accounts to inventory, systems to configure and evidence to collect. A store with a few admins on one hosting provider and no third-party remote access is a much smaller exercise than a multi-site setup with agencies, contractors and a separate infrastructure team. Confirm the count of admin accounts and vendor access paths before you request a quote, so the scope can be sized against them.

Is requirement 8 work on a Magento store a one-time project?

The configuration is largely one-time. It covers password length and history rules, lockout thresholds, unique account rules, and multi-factor authentication for admin login, remote access, and the servers and databases behind the store. Other work recurs: periodic access reviews, removing leavers, changing vendor access, keeping evidence current, and re-checking settings after Magento patch upgrades or identity provider changes. Requirement 8 applies on an ongoing basis, so the recurring part is what an assessor is most likely to sample. Ask any provider to split the quote into one-time setup and recurring activities, and to name who performs each recurring review.

Can our internal team complete requirement 8 work without an outside partner?

A team can do it internally, especially if it already runs an identity provider, has mature change control and has worked through PCI DSS v4.x requirement 8 before. The difficulty is that the work spans several areas: Magento admin settings, the hosting layer, VPN or bastion access, database accounts and vendor remote access. Gaps often appear where ownership is split between the store team and infrastructure. Check who will own each control and the evidence, and whether someone can test the configuration independently. A partner can take on configuration, testing and evidence packaging while your team keeps the decisions. Either way, validation comes from your assessor, not from the implementer.

What does a requirement 8 engagement need from our own staff?

Expect to name people in several roles: an admin who can approve account changes, an infrastructure engineer for multi-factor authentication on servers and databases, a network owner for remote access paths, and someone from HR or store operations who confirms joiners, movers and leavers. You will also need a complete list of vendors and how each one connects. Staff time goes to interviews, access exports, testing sign-in flows with the admin team and reviewing the configuration. Ask the provider which inputs it needs, when, and in what format, and agree on a single owner for each input before work starts.

How does our PCI DSS assessment type change the requirement 8 workload?

The assessment type changes how much evidence you must produce and who reviews it. An entity completing a Report on Compliance is assessed by a Qualified Security Assessor, who samples accounts, configurations and logs. An entity completing a Self-Assessment Questionnaire fills in the relevant SAQ and an Attestation of Compliance, and gathers the evidence itself. The payment brands decide which entities must validate, so confirm the requirement with your acquirer. PCI SSC does not recognize compliance certificates as validation. Ask your acquirer which SAQ or ROC applies, and whether your assessor expects a defined or customized approach for any requirement 8 control.

How do vendors with remote access affect the scope of requirement 8?

Requirement 8.4.3 calls for multi-factor authentication on all remote network access from outside your network that could access or affect the cardholder data environment, including third parties and vendors. Each vendor path, such as a VPN account, jump host, remote support tool or agency login to the admin, becomes its own item to inventory and test. Shared logins used by vendor staff add work, because requirement 8 expects unique accounts for each person. Ask for a list of every remote access path, the people who hold it, and whether it passes through a gateway your team controls.

What should a written quote for requirement 8 work include?

A written quote should follow the agreed scope and list the systems in scope, such as Magento admin, hosting, VPN, server and database access, and the identity provider. It should state the admin account count and vendor paths it assumes, the controls to configure, the testing method, the evidence package and the assessment type. It should also divide responsibilities between your team and the provider, list assumptions and exclusions, and define deliverables and acceptance criteria. Ask for one-time and recurring elements priced separately, the fee basis, what triggers a change request, and how extra evidence requests from your assessor are handled. DeployOpen works from a written scope and does not publish a price list, so the quote is where costs are set.

How long will a requirement 8 engagement take to finish?

A duration cannot be stated without a confirmed scope. Elapsed time depends on the number of admin accounts and vendor paths, whether your identity provider already enforces multi-factor authentication, how many hosts and databases need changes, change windows, and when your assessor needs the evidence. Delays tend to come from waiting on access exports and vendor responses, more than from configuration. Ask for a timeline with milestones tied to your inputs, the dependencies that could move it, and the point where assessor review begins. Start with your target assessment date so the plan works backward from it.

How DeployOpen scopes and prepares requirement 8 controls and evidence

DeployOpen plans and builds the identity and access setup behind a self-hosted Magento Open Source store inside infrastructure you control, then prepares the configuration records and evidence your assessor will ask for under PCI DSS requirement 8. We do not issue attestations or certifications; your Qualified Security Assessor or the relevant assessment template owner makes that determination.

How we scope

Engagements are fixed-scope, so the written scope lists each admin account group, the MFA provider and the servers and databases covered for requirement 8.
We map which admin paths, shell accounts, database users and remote access routes touch the cardholder data environment before any configuration change.
The scope states which requirement 8 sub-requirements apply to your assessment type, and which ones your assessor must confirm with you.

How we build

We configure Magento Admin password length, lockout thresholds and password history to match the requirement 8.3 values, then test each setting with a sample account.
We set up MFA for admin logins and remote access paths, then verify that service and application accounts are excluded only where requirement 8.4.2 allows.
We define unique named accounts per person, remove shared logins, and document each role change so access reviews can be reproduced.

How we hand over

You receive a configuration record for each control, with the setting value, the owner, the test performed and the date it was verified.
We provide a test script and results for lockout, password rules, MFA enrollment and remote access, so your team can rerun them after upgrades.
Handover includes an evidence index mapping each requirement 8 control to the screenshots, logs and tickets your assessor will request.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, which covers re-verifying requirement 8 settings after each Magento patch.
We review MFA provider changes, admin role changes and new remote access paths against the written scope before they reach production.
Ask us to confirm the support hours, response terms and upgrade coverage in writing before you sign, since these are set in each scope.

Magento Open Source admin access for PCI DSS requirement 8