MFA Exception on the Customer Portal
Helios Insurance's customer portal runs on a vendor product that cannot support multi-factor authentication; the vendor's roadmap promises it in 14 months. The portal is internet-facing, serves 200,000 policyholders, and allows profile and payment-detail changes. It is protected today by a WAF, IP reputation filtering, and anomaly alerting on logins. Last month an attacker used credential stuffing from 4,000 distinct IPs and successfully logged into 11 accounts; a WAF rule tuned afterward blocked 92% of the next campaign. The business owner wants to accept the risk for 14 months and sign the exception. The CIO asks the risk practitioner whether the compensating controls are adequate.
1. Are the existing compensating controls adequate to justify a 14-month exception? Explain what the controls do and do not address.
Read the worked answer
Not adequate. The controls address volume, not compromise. IP reputation and the WAF reduce hostile traffic, but the 11 successful logins prove the credentials were valid - and neither control can distinguish a valid stolen credential from the real customer.
Compensating controls must map to the specific threat, which here is credential compromise. Require breached-password screening against known-compromised lists, bot detection with device fingerprinting, step-up out-of-band verification for payment-detail and profile changes, transaction velocity limits, and alerting tuned to account-takeover patterns rather than generic logins.
Do not extrapolate from two weeks of blocked traffic. A 92% block rate on one follow-on campaign says the tuned rule works against that campaign; it says nothing about the next one, and an attacker who needs 11 successes out of tens of thousands of attempts is not deterred by a 92% block rate.
2. Who may accept this residual risk, and under what conditions?
Read the worked answer
Authority follows the risk, not the org chart. With 200,000 data subjects, live payment capability, and demonstrated successful compromise, this exposure likely exceeds the business owner's delegated limit. The business owner may propose acceptance, but concurrence should sit with the CISO and risk committee, and probably the board given scale and regulatory notification obligations.
Any acceptance must be:
- Time-bound to the vendor's 14-month commitment, with a hard review at 12 months, not an open-ended signature.
- Conditional on the interim measures above being funded and operating, not merely planned.
- Instrumented with a KRI on successful account takeovers and on blocked credential-stuffing volume, reported monthly.
- Re-openable - a written trigger that revokes the exception if the vendor roadmap slips or a further compromise occurs, rather than a silent extension.
An exception that outlives its justification is an accepted control failure.
3. What information would you require before any signature, and why does each item matter?
Read the worked answer
Four items, each closing a different gap:
- Fraud and abuse loss history for the portal - converts an opinion about likelihood into a measured rate the business owner can be held to.
- Notification obligations and cost per affected record under applicable regulation - this is often the largest line in the loss, and it is absent from any technical assessment.
- The vendor's contractual liability cap - establishes how much of the loss actually transfers to the party that cannot deliver MFA, and whether the 14-month delay carries any cost to them.
- A written residual-risk statement in the same units as the appetite statement - so the acceptance can be tested against what the board has said it will tolerate.
Also require an exit or data-portability clause and firm pricing for the interim controls. Without these, the signature certifies an opinion rather than a decision.