Retail and E-Commerce Identity Security Guide: Protecting Customers and Stores

Retailers run one of the hardest identity estates to secure: thousands of frontline staff on shared devices, outsourced help desks and suppliers with privileged access, millions of customer accounts, and an online store wired to payment, cloud and marketing services by API keys. The 2025 attacks on UK retailers showed that attackers do not need an exploit when a help desk will reset a password for them, and the 2026 agent-driven card theft campaign showed how quickly one leaked database password becomes a skimmer on a checkout page. This guide covers workforce, third-party, customer and machine identities across stores, warehouses and e-commerce, mapped to PCI DSS v4.0.1 Requirements 7 and 8. It is written for retail security, IAM and e-commerce engineering teams, and for the compliance leads who sign the PCI attestation.

Key takeaways

• The help desk is a login page. A password or MFA reset granted on the strength of a phone call is an authentication event, and in 2025 it was the entry point for attacks on major UK retailers.
• Third parties carry your privileges. Outsourced IT, store systems integrators and agencies often hold administrator access; hold them to the same verification, MFA and review standard as staff.
• Frontline identity needs its own design. Shared tills, handhelds and kiosks call for shared device sign-in and fast badge or passkey flows, not shared passwords taped to the counter.
• E-commerce runs on machine identities. Database passwords in config files, broad cloud keys and payment API keys are what turns a web bug into card theft.
• PCI DSS v4.0.1 is the floor, not the plan. Requirement 8.4.2 MFA for all CDE access, 12-character passwords and system account controls are mandatory now, but they do not cover customer accounts or most of the corporate estate.

The retail identity landscape

A retailer typically manages five identity populations, each with a different threat and a different owner. Treating them as one programme with separate policies is what keeps gaps from opening between teams.

Omnichannel operations make the lines blur. Click and collect, ship from store and returns link store staff, logistics partners and customer accounts in one transaction, so an identity weakness in one population often surfaces as fraud in another.

Help desk and password reset security

The FBI and CISA advisory on Scattered Spider (AA23-320A) describes the technique precisely: callers posing as employees persuade help desk staff to reset passwords or MFA, then use single sign-on to reach everything the account can reach. The advisory maps this to Spearphishing Voice (T1566.004), Trusted Relationship (T1199) and Valid Accounts (T1078), and notes that attackers then register their own MFA methods (T1556.006). Retail help desks are a natural target: large, often outsourced, under pressure to get store managers back online before opening.

• Verification that cannot be researched: do not accept date of birth, employee number, store number or manager name as proof. Use a call-back to a number in the HR system, a manager approval in a workflow tool, a video check against an ID document, or an in-person check at a store.
• Tiered resets: standard users may self-serve with a registered phishing-resistant method; administrators, finance and help desk staff themselves need two-person approval for any reset or new MFA registration.
• Time-limited bootstrap: issue a short-lived one-time onboarding code (for example a Temporary Access Pass in Microsoft Entra ID) rather than a new password, so a reset does not produce a reusable credential.
• Suppliers follow your rules: write the verification procedure into the outsourcing contract and test it with unannounced calls.
• Alert on the pattern: reset, then new MFA registration, then sign-in from a new device or country, then privileged activity, within hours.

See the Account Recovery and Help Desk Security Guide and the Scattered Spider Threat Actor Profile.

Frontline and store identity

Store staff change rapidly, work on shared hardware, and often have no corporate email address or managed phone. The usual failure is a single shared login per store, or a till PIN known to every past employee.

Shared devices

• Shared device sign-in: platforms such as Microsoft Entra shared device mode on iOS, iPadOS and Android sign a worker in once for all supported apps and sign them out of all of them at the end of a shift. It requires MDM provisioning (the MDM pushes Microsoft Authenticator with shared device mode on, plus the Enterprise SSO plug-in on iOS) and apps that clear the previous user's cached data.
• Device compliance as a factor: require a managed, compliant device through Conditional Access or equivalent, so a stolen password alone does not open the staff app from a personal phone.
• Fast, personal authentication: badge tap plus PIN, or a passkey on a managed device, gives each worker an individual identity without slowing the queue. See the Passkey Rollout Guide.

POS and back-office accounts

• Individual POS IDs: PCI DSS 8.2.2 allows shared or generic accounts only by exception, with individual accountability. Supervisor overrides for refunds, voids and price changes should record the individual, which is also the main control against refund and return fraud by insiders.
• Seasonal joiners and leavers: drive account creation and removal from the HR or workforce management system. Peak season hiring is the moment manual processes fail, and disabling dormant accounts (CIS Control 5.3) catches what HR misses.
• Store manager privilege: separate the manager's everyday account from any account that can change POS configuration, payment terminal settings or staff permissions.

Third-party and supplier access

Marks and Spencer told Parliament that the April 2025 attack involved impersonation of an individual combined with a third-party vector, and the reporting links it to the outsourced IT help desk. The Marks and Spencer cyberattack 2025 cost an estimated £300 million in profit before recoveries, and online orders were paused for weeks. Retailers depend on suppliers for service desk, store technology, logistics, payment integration and marketing, and each brings accounts.

See the Third-Party Access Guide and the RMM Tool Security Guide.

Customer accounts, loyalty and fraud

Customer accounts are attacked at scale with reused passwords (Credential Stuffing, T1110.004), and the prize is usually stored value: loyalty points, gift card balances, saved cards and delivery address changes. This guide does not repeat the CIAM, bot and credential stuffing guides; it sets out the retail-specific decisions.

• Protect stored value, not just login: require step-up authentication for redeeming points, adding a gift card, changing the delivery address or email, and adding a new payment method, because those are the cash-out steps.
• Offer passkeys at checkout and account creation: they remove the reused password that stuffing depends on. See the Passwordless and Passkeys Guide.
• Guest checkout and account linking: do not silently attach guest orders to an account on email match alone; confirm control of the email first.
• Bots and scalping: limited releases and gift card balance checkers attract automated abuse; handle them with bot management rather than account lockout, which punishes real customers. See the Bot Management Guide.
• Customer support channels: the same impersonation that targets the staff help desk targets customer service; agents should not change account email or phone numbers on request without verification through an existing factor.

See the Customer IAM (CIAM) Guide and the Password Spraying and Credential Stuffing Defence Guide.

E-commerce platforms, machine identities and skimming

An online store is a cluster of non-human identities: database credentials, payment gateway API keys, cloud access keys for storage and CDN, tag manager and analytics accounts, and the platform's own admin accounts. Gambit Security's interim report on the 2026 campaign, summarised in the AI agent retail card theft campaign 2026, describes AI agents chaining SQL injection to plaintext one-time passcodes, database passwords in wp-config.php, 46 secrets from AWS Secrets Manager and a Magento encryption key. At one retailer an AWS key with write access to the CDN bucket let the attacker serve a skimmer from the store's own infrastructure. Gambit reports more than 600,000 payment cards taken; the report is interim and most victims are unnamed.

PCI DSS 6.4.3 requires an inventory of every script on payment pages with its authorisation and justification, and 11.6.1 requires detection of unauthorised changes to payment pages at least every seven days (or at a frequency set by targeted risk analysis). The January 2025 SAQ A removed 6.4.3 and 11.6.1 from that questionnaire but added an eligibility condition that the merchant's site is not susceptible to script attacks; the PCI SSC states the underlying requirements were not removed. In identity terms, the question is who and what can change a payment page: every account and key with that right belongs in scope. See the Client-Side Security Guide.

AI shopping and service agents

Retailers are deploying AI agents for customer service and are starting to receive orders from customers' own shopping agents. A service agent that can issue refunds, change addresses or look up orders holds real authority; OWASP's Top 10 for LLM Applications 2025 lists Excessive Agency (LLM06) for exactly this case. Give agents their own scoped identities, cap refund values, require human approval above thresholds, and log every action against the agent identity. See the Agentic Commerce Identity Guide.

PCI DSS v4.0.1 identity requirements

PCI DSS v4.0.1 was published by the PCI Security Standards Council in June 2024 as a limited revision of v4.0, with no new or removed requirements; v4.0 retired on 31 December 2024 and the future-dated requirements became effective on 31 March 2025. The identity requirements below apply to the cardholder data environment (CDE) and systems connected to it.

The fastest way to shrink this table is to shrink scope: hosted payment pages, tokenisation and point-to-point encryption at the terminal keep card data out of most systems. See the PCI DSS 4.0 Guide and the PCI DSS Readiness Checklist.

How to implement

1. Inventory (weeks 1 to 4): list every identity store, every supplier with accounts, every machine credential in the e-commerce stack and every account that can reset passwords or change payment pages.
2. Fix the help desk first (weeks 2 to 6): publish the verification procedure, apply it to outsourced desks, add two-person approval for privileged resets and turn on the reset-then-new-device alert.
3. Phishing-resistant MFA for administrators and suppliers (months 2 to 3): pilot with IT and security, then extend to supplier admin accounts and e-commerce platform admins. Keep the old method available during a pilot ring so rollback is a policy change, not a support crisis.
4. Secrets and keys (months 2 to 4): scan code and config for credentials, move them to a secrets manager with per-workload policies, rotate anything that was exposed and remove write access to production CDN from web roles.
5. Frontline rollout (months 3 to 6): pilot shared device sign-in in a handful of stores, measure queue and sign-in times, then roll out by region ahead of peak season, not during it.
6. Customer passkeys and step-up (months 4 to 9): offer passkeys at sign-in and checkout, add step-up on cash-out actions, and run in monitor mode first to tune false positives.
7. Review and test (ongoing): six-monthly access reviews (PCI DSS 7.2.4), unannounced help desk tests and a tabletop exercise based on the 2025 retail attacks.

Decision guidance

• Synced or device-bound passkeys: synced passkeys suit customers and most head office staff; device-bound keys or managed device passkeys suit administrators, help desk staff and supplier admins.
• Badge plus PIN or passkey for stores: badge plus PIN is quicker on shared tills; passkeys on managed handhelds give stronger assurance for manager functions.
• Outsource the help desk or not: outsourcing is workable if the contract fixes the verification standard and you can audit it; if you cannot audit it, keep privileged resets in house.
• Small retailer or large group: a small online shop on a hosted platform should focus on admin MFA, removing agency logins and SAQ eligibility; a group with stores, data centres and marketplaces needs IGA, PAM and a CIAM platform.

Detection and measurement

• Log: password and MFA resets with the approver, new MFA registrations (Device Registration, T1098.005), MFA push storms (T1621), supplier sign-ins, secret reads and bulk reads, payment page changes, and loyalty and gift card redemptions.
• Correlate: reset followed by new device and privileged action; secret read by an unexpected workload; spike in failed customer logins from one autonomous system.

Framework mapping

Common failure patterns

• Reset on a phone call: the Co-op cyber attack 2025 reportedly began with attackers posing as staff to obtain a password reset, then going after the Active Directory database (NTDS, T1003.003); data on 6.5 million members was taken.
• Supplier accounts outside the programme: outsourced desks and integrators with standing admin rights that are never reviewed with staff accounts.
• Shared store credentials: one login per store or a till PIN shared by every shift, which makes leavers impossible to remove and fraud impossible to attribute.
• Secrets in the web tier: database passwords in config files and cloud keys that can write to the CDN, as in the 2026 card theft campaign.
• MFA that can be replayed: OTPs stored in plaintext or push approvals without number matching, which fail PCI DSS 8.5.1 in spirit even when MFA is "on".
• Peak season exceptions: controls relaxed for trading periods and never restored.

Practitioner checklist

• Publish a help desk verification procedure that excludes researchable facts and apply it to every outsourced desk.
• Require two-person approval for resets and MFA changes on privileged, finance and help desk accounts.
• Move administrators, supplier admins and e-commerce platform admins to phishing-resistant MFA.
• Remove shared store and POS logins; give every worker an individual identity on shared devices.
• Drive staff and seasonal joiners and leavers from HR data and disable dormant accounts automatically.
• Scan the e-commerce stack for credentials in code and config, move them to a secrets manager and rotate them.
• List every account and key that can change a payment page or script, and alert on changes.
• Add step-up authentication for loyalty redemption, gift cards, address and payment method changes.
• Run six-monthly access reviews covering suppliers and system accounts.
• Rehearse the 2025 retail attack chain in a tabletop exercise with the outsourced desk present.

Standards and references

• PCI Security Standards Council: Just Published: PCI DSS v4.0.1
• PCI Security Standards Council: Important Updates Announced for Merchants Validating to Self-Assessment Questionnaire A
• CISA and FBI: Scattered Spider Cybersecurity Advisory AA23-320A
• Microsoft Learn: Overview of shared device mode
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• OWASP: Top 10 for LLM Applications 2025
• SecurityMetrics: A Guide to New Requirements in PCI DSS 4.0.1

Related NHI Mgmt Group resources: Customer IAM (CIAM) Guide · Account Recovery and Help Desk Security Guide · PCI DSS 4.0 Guide · Fraud Prevention Guide for Digital Businesses · Small Business Identity and Access Security Guide