What Happened
In the first half of 2026, Resilience's Risk Operations Center analyzed paid claims across its cyber insurance portfolio. The data revealed a stark concentration: social engineering attacks accounted for 85% of incurred losses, up from 17% two years prior. Payment fraud losses tripled year-over-year. Meanwhile, attacks using AI-native techniques (prompt injection, model exploitation, agentic misuse) generated zero incurred losses during the same period.
This isn't a data anomaly. It's a pattern that should reshape how you allocate your security budget.
Timeline
2024: Social engineering represented 17% of incurred losses in Resilience's portfolio. Organizations treated it as one threat among many.
First Half 2026: Social engineering jumped to 85% of incurred losses. Payment fraud losses tripled. AI-native attack techniques produced no measurable financial impact in claims data.
The shift happened in under two years. Your threat model probably hasn't kept pace.
Which Controls Failed or Were Missing
The claims data points to three recurring control gaps:
Credential validation broke down. When social engineering drives 85% of losses, your authentication controls aren't stopping attackers who've convinced someone to hand over access. Multi-Factor Authentication (MFA) was either absent, implemented with phishable factors (SMS codes, push notifications without context), or bypassed through session hijacking after initial compromise.
Payment authorization workflows had insufficient verification. A tripling of payment fraud losses means attackers successfully initiated fraudulent wire transfers, ACH payments, or card transactions. Your dual-authorization requirements either didn't exist, were implemented in a way that the same social engineering vector could compromise both approvers, or lacked out-of-band verification for high-value transactions.
User activity monitoring didn't catch anomalous behavior. Claims materialized because fraudulent payments cleared, data was exfiltrated, or ransomware was deployed before anyone noticed. Your Security Information and Event Management (SIEM) rules weren't tuned to detect credential use from new locations, unusual payment patterns, or bulk data access following a credential compromise.
What the Relevant Standards Require
PCI DSS Requirement 8.3 mandates MFA for all individual non-console administrative access and all remote network access to the cardholder data environment. But the standard doesn't specify which factors. SMS-based codes satisfy the letter of the requirement while remaining vulnerable to SIM swapping and phishing. NIST SP 800-63B classifies SMS as a restricted authenticator precisely because of these weaknesses. If you're meeting PCI DSS 8.3 with SMS codes, you're compliant and exposed.
FFIEC IT Examination Handbook guidance on retail payment systems requires layered controls for funds transfer authorization, including dual authorization for transactions above certain thresholds and out-of-band verification for unusual requests. The handbook specifically addresses social engineering risk in its authentication section, noting that controls must verify both the identity of the requester and the legitimacy of the request itself.
NIST Cybersecurity Framework Function PR.AC-7 calls for users, devices, and other assets to be authenticated before being granted access. But authentication proves who you are, not whether you should be doing what you're doing. The framework's Detect function (DE.CM) requires monitoring for anomalous activity and events. Your claims data is telling you that detection failed.
Lessons and Action Items for Your Team
Prioritize defenses based on demonstrated loss, not hypothetical scenarios. You're probably tracking AI-native threats in your risk register. That's prudent. But zero incurred losses from prompt injection versus 85% from social engineering means your next budget cycle should fund phishing-resistant MFA and payment verification controls before it funds AI model security.
Implement phishing-resistant MFA everywhere credentials grant payment authority. FIDO2 hardware tokens and platform authenticators (Windows Hello, Touch ID) resist credential phishing because the cryptographic challenge-response can't be proxied to an attacker's site. Deploy them first for treasury staff, accounts payable approvers, and anyone with wire transfer authority. PCI DSS doesn't require this level of protection, but your claims data does.
Add out-of-band verification for payment requests that deviate from patterns. When someone requests a wire transfer to a new beneficiary, a payment above typical thresholds, or a change to standing payment instructions, require confirmation through a separate communication channel. A phone call to a known number works. An approval link sent to a registered mobile device works. An email reply to the same thread doesn't work (the attacker controls the inbox).
Tune your SIEM to flag credential use that follows common social engineering patterns. Alert on: authentication from a new country within 24 hours of a password reset, payment authorization from a user who's never approved payments before, bulk email forwarding rules created within an hour of successful login, and VPN connections immediately followed by access to financial systems. These patterns appear in successful social engineering incidents. If your SIEM isn't looking for them, you're waiting for the claim.
Use claims data from your cyber insurer as a control validation tool. If you carry cyber insurance, request anonymized claims data from your carrier. Ask which attack vectors led to paid claims in your industry segment, what the median time-to-detection was, and which controls were present in incidents that didn't result in loss. This data tells you whether your layered defenses would have stopped real attacks against organizations like yours.
The threat landscape hasn't fundamentally changed. AI made the same attacks faster and more convincing. Your controls need to assume the phishing email is perfect, the voice on the phone sounds exactly like your CFO, and the payment request looks legitimate. Design for that reality, and your organization won't appear in next year's claims data.
