How PCI DSS requirement 8 treats shared logins at online stores and agencies

PCI DSS is the data security standard for payment card data, set by the PCI Security Standards Council (PCI SSC). Its requirement 8 covers how people are identified and signed in. Requirement 8.2.2 allows shared logins only on an exception basis, and only if every action can be traced to one person. The PCI SSC’s FAQ says this covers all shared logins, not just admin accounts. The note to requirement 8.2.4 applies its account rules to third-party vendors as well as employees, so it covers an agency’s people who sign in to the store.

Who PCI DSS applies to

The current version is v4.0.1, published in June 2024. The PCI SSC says it added and removed no requirements, and v4.0 retired on December 31, 2024. The standard applies to businesses that store, process or transmit cardholder data, such as merchants, payment processors and service providers. Whether you must prove compliance, and how, isn’t set by the PCI SSC. Its FAQ 1473 says payment brands and acquirers, the banks that handle a merchant’s card payments, decide the method and the form of evidence.

What 8.2.2 requires of a shared login

The requirement text, as the PCI SSC prints it in its v4.0 self-assessment questionnaires (SAQs), says group, shared or generic accounts are used only when necessary on an exception basis. It then lists six conditions:

1. Use is prevented unless an exceptional circumstance needs it.
2. Use lasts only as long as that circumstance.
3. The business reason is documented.
4. Management explicitly approves the use.
5. The person’s identity is confirmed before they get into the account.
6. Every action taken can be attributed to an individual user.

The FAQ on 8.2.2 explains why. When each user is identified, every action traces to a person, so misuse can be investigated and contained faster. A shared login breaks that link. The platform’s log shows the account name, and finding out who was using it at a given time takes a separate record.

The same FAQ allows tools or password vaults for admin work, to manage and limit shared IDs while confirming each person and keeping an audit trail. Its example is emergency, or “break the glass”, admin access. How that kind of account is usually set up is in What is a break-glass account?

Other parts of requirement 8 that a shared login makes harder

Version 4.0.1 added a note to 8.4.2. MFA for non-admin access into the cardholder data environment doesn’t apply to accounts that sign in only with phishing-resistant factors.

FAQ 1066 explains the 90-day rule: inactive accounts tend not to be watched, so a change to them can go unnoticed. Passwords have one more rule. Under 8.3.9, a password used as the only factor must change at least every 90 days, unless account risk is analyzed continuously instead. FAQ 1590 says 8.3.9 doesn’t apply where MFA is used. How teams handle a second factor on a shared login is in Sharing two-step verification across a team.

US online stores and SAQ A

A US online store that sends customers to a payment provider’s page, instead of taking card numbers on its own site, may qualify for SAQ A. In the PCI SSC’s January 2025 description, SAQ A covers e-commerce and mail or phone-order merchants that outsource all payment data handling to validated, compliant third parties. They must keep no card data in electronic form, only paper reports or receipts. The v4.0 SAQ A also required e-commerce stores to confirm that every element of the payment page comes directly from a compliant provider. A newer criterion asks them to confirm their site isn’t open to script attacks that could affect their e-commerce systems.

Requirement 8 still reaches these stores. In the SAQ A written for v4.0, the PCI SSC noted that requirement 8 applies to the store’s web server that hosts the page giving customers the payment page’s address. That version of SAQ A included 8.2.1, 8.2.2 and 8.2.5. Its January 2025 revision for v4.0.1 removed 6.4.3 and 11.6.1 on payment page security, and 12.3.1, the risk analysis that supports 11.6.1. Check the current SAQ A for the requirement 8 items it keeps, and ask your acquirer which form applies to you.

Agencies and other service providers

Agencies that run a client’s store, ads or customer service may sign in to the store’s admin. The note to 8.2.4 says the account rules apply to all user accounts, including third-party vendors. So an agency’s people need the same treatment as store staff. Each person gets their own user where the platform allows it, and a person who leaves the agency loses access right away. Store platforms’ staff accounts are covered in Getting agency staff into a client’s Shopify or BigCommerce store.

When a merchant uses outside providers for work tied to card data, FAQ 1312 says this affects the merchant’s own compliance. The merchant must monitor each provider’s compliance status at least once a year. The merchant also has to know which requirements it covers and which the provider covers. Use the same idea for store admin logins. Write down who creates users, who receives two-step verification codes, and who removes access when someone leaves.

If a shared login has to stay

Some admin consoles don’t allow a separate user for each person. If you keep a shared login, set it up so each condition in 8.2.2 has an answer:

1. List each shared login and why it can’t be split, with management’s approval on record.
2. Confirm who each person is before they get in, and keep a record of who used the login and when.
3. Decide how a person loses access when they leave. If they know the password, that means changing it and telling everyone else.
4. Decide who receives two-step verification codes, so work doesn’t stop when that person is away.