The identity shape of a retailer
Retail’s identity challenge is distribution and turnover, wrapped around payment data:
- The workforce is seasonal and high-churn. Hundreds of temporary staff onboarded for a peak and offboarded after it. At that speed, access gets granted broadly and removed late, if at all.
- The estate is spread across every store. Point-of-sale systems, back-office machines, stock and store-management systems — replicated across every location, each a place someone logs in.
- Card data sets the rules. Wherever payment card data is handled, PCI DSS applies, and its access-control requirements are specific and audited.
- Suppliers and head office both reach in. Logistics providers, e-commerce platforms and head-office administrators all touch store and back-office systems remotely.
The person you onboarded for six weeks of peak still has their access in week ten, because offboarding a thousand seasonal staff is nobody’s favourite job.
Where the exposure concentrates
Retail breaches cluster around two things: payment systems and forgotten access. Point-of-sale and back-office administration, reached with credentials that are shared, weak, or belong to someone who left after the season. The store manager’s account that opens more than it should. And the supplier or e-commerce integration whose access was scoped generously and never revisited. Card data makes any of these expensive.
What the rules require
No product confers compliance. But retail sits under card-data rules that are unusually prescriptive about access, and the requirements below are the ones an assessor opens first.
| Framework | The access-control requirement |
|---|---|
| PCI DSS v4.x | Multi-factor authentication for all administrative access and all access into the cardholder data environment, unique IDs for every user, and no shared accounts (Req. 8.2, 8.4, 8.5) |
| GDPR — Art. 32 | Appropriate technical measures for access to customer personal data across e-commerce and loyalty systems |
| ISO/IEC 27001:2022 | Access control and authentication across a distributed estate as part of the management system |
Where to start
1. Centralise authentication across connected applications
Single sign-on centralises authentication across connected applications. When the central identity is disabled, federated access stops without relying on separate passwords at every application — which shortens the tail that a seasonal intake otherwise leaves behind.
2. Take the reset spike off the help desk
Seasonal peaks create password-reset peaks too. Self-service password reset lets staff reset passwords and unlock accounts without sending every store back to the help desk, and it covers the evenings and weekends when stores are open and the desk isn’t.
3. Put MFA on the paths an assessment looks at
Point-of-sale administration, back-office machines and the VPN into stores get a second factor — over RADIUS for the network devices, at the logon for the store and back-office machines. Together those cover the administrative and remote-access paths PCI assessments focus on.
4. Make shared store accounts attributable
PCI asks for a unique identity per user and no shared logins. Where an underlying shared privileged account still exists, Mirket PAM keeps the credential away from the user while attributing every session to the named person who launched it — and records what was done inside it.
5. Scope supplier and integration access
Third-party and vendor access gives logistics and e-commerce partners a recorded, session-scoped path rather than a standing account into the estate. Give the partner access for the support or maintenance window, then let the access expire.
What changes
| Today | With Mirket |
|---|---|
| Seasonal staff retain separate application access after leaving | Disable the central identity and federated access stops across connected applications |
| Reset volume spikes during peak hiring periods | Staff reset passwords and unlock accounts themselves |
| Store and back-office admin relies on shared credentials | PAM attributes each privileged session to a named user |
| Store machines rely on password-only Windows logon | Windows logon and RDP can require MFA |
| Remote store access relies on password-only VPN authentication | VPN and firewall authentication can require MFA |
| Supplier access remains broad and standing | Partners receive scoped, recorded, time-bounded access |
Related
Solutions — Self-Service Password Reset · VPN & Firewall MFA · Operating System Logon MFA · Third-Party & Vendor Access · Just-in-Time Access
Products — Multi-Factor Authentication · Single Sign-On · Privileged Access Management
