MFA Mandate Meets Shared Shift Accounts and a Legacy Payroll Application
Halcyon Retail (2,300 employees, 180 stores) is moving its POS back office and HR systems to a SaaS provider. The security team's draft requirement reads: "all users must use MFA for all systems." Elicitation reveals that 900 seasonal store associates share 12 generic shift accounts on the POS back office; 40 HR staff access the HR system from personal phones; a 2009 payroll application authenticates against Active Directory over NTLM and cannot be changed before the vendor's 2027 roadmap; and an offshore contact-centre outsourcer with 300 agents needs the customer-service console with a contractual 15-minute onboarding SLA at peak. Store managers report associates forget passwords weekly, costing about six manager-hours per store per month. Cutover is in six months. PCI DSS applies to the POS back office and GDPR applies to HR data.
1. Why does the single MFA statement fail as a requirement, and how would you restructure it?
Read the worked answer
It fails on three counts: it cannot be verified (which systems, which users, what counts as MFA?), it is not achievable for the NTLM payroll application, and it silently ignores the shared accounts, which are the real risk.
Restructure into a set of requirements, each carrying rationale, source, priority, owner and fit criterion:
- Population split. Named-user MFA for all human access to the POS back office, HR and customer-service console; a separate requirement for agents, since their identity source is the outsourcer's IdP.
- Generic accounts. Shared shift accounts shall be eliminated in favour of individually attributable accounts, with a per-associate credential issued at store level. The fit criterion is an inventory showing zero shared credentials in use. This is the requirement that actually reduces the PCI exposure; MFA over a shared account still leaves actions unattributable.
- The legacy payroll app. Don't write an impossible requirement. Write a transitional requirement (network restriction to a defined host set, compensating monitoring) with a fit criterion and an expiry date tied to the 2027 vendor roadmap, and record the constraint and the risk acceptance.
- Personal devices. A requirement about the authentication method acceptable on unmanaged phones (e.g. push or TOTP, with what is stored), not a blanket ban.
Each of these traces to PCI DSS or GDPR obligations, which is what justifies its priority.
2. The outsourcer's 15-minute onboarding SLA conflicts with the security team's approval workflow. How do you analyse and resolve it?
Read the worked answer
First, quantify the conflict rather than debating it. The SLA applies at peak; the security workflow (manual approval by a Halcyon manager) has an observed turnaround that must be measured before any option is chosen. If manual approval averages two hours, the SLA is already being breached and the requirement is fictional.
Options to put to the stakeholders, with trade-offs stated:
- Federated, just-in-time provisioning. Agent identities live in the outsourcer's IdP; Halcyon authorizes by role, and entitlement is created at first login and revoked automatically at contract-defined triggers. Meets the SLA by design; requires a trust configuration and a contractual obligation on the outsourcer's own joiner/leaver process.
- Pre-provisioned pool with manager attestation. Faster, but creates dormant accounts - a real risk the security team will (rightly) raise.
- Retain manual approval and renegotiate the SLA. Acceptable only if the business can show the 15 minutes is not a genuine operational need.
Resolution artefact: a decision record naming the chosen option, the residual risk (Halcyon cedes control of the outsourcer's internal leaver process), the compensating control (reconciliation report of active agents versus the outsourcer's roster, run weekly), and the contract clauses that make it enforceable. The requirement is then written against the chosen option, not against the ideal.
3. Which requirements in this programme are most likely to conflict at validation, and how do you detect that early?
Read the worked answer
The predictable collisions are:
- Usability versus attribution: eliminating shared shift accounts raises the password-reset load the stores already complain about (six manager-hours per store per month). If the identity requirements do not include a self-service reset or badge-based sign-in requirement, the shared accounts will quietly return after go-live. I would pair the two requirements explicitly and write a fit criterion on reset volume.
- PCI scope versus HR convenience: personal-phone MFA for HR staff may pull unmanaged devices into scope debates; the two requirements must be checked against each other before sign-off.
- SLA versus approval: as above.
Detection method: a requirements traceability matrix plus a structured walkthrough with security, store operations and the outsourcer in the same room, checking each requirement pair for a shared resource or opposing fit criterion. Any pair that cannot both pass is logged as a conflict with an owner and a decision date - not left for the test phase, where it becomes a change request.