Phishing is not a niche threat or an edge case. It remains one of the most common cyber threats facing organizations of every size, and it is getting harder to defend against, not easier. Generative AI has lowered the bar for convincing, personalized lures to near zero, and the assumption that more security awareness training will close the gap is a strategy that the data simply does not support.
The uncomfortable reality is that human error will always exist, and attackers are increasingly engineering around every safeguard training can provide. The organizations winning this fight are not the ones with the most polished phishing simulations. They are the ones that have made phishing technically difficult to succeed, even when an employee clicks.
This analysis walks mid-market security leaders through that architecture. You will find a breakdown of what phishing-resistant controls actually mean in practice, a prioritized deployment framework built around real operational constraints, and the key metrics that demonstrate measurable exposure reduction. From FIDO2 and passkeys to DMARC enforcement and adaptive MFA, the stack exists. The question is how to build it in the right order.
The Losing Game of Training-First Security
Security awareness training has been the industry’s default response to phishing for more than a decade. The investment case was straightforward: teach employees to recognize the signs of a phishing email, run regular simulations to reinforce the behavior, and watch click rates fall. The problem is that phishing remains one of the most persistent initial access vectors for breaches, and the evidence that organizations need practical solutions to phishing attacks has only grown stronger despite years of training investment. The approach is not compounding in effectiveness the way security leaders were promised it would.
The core reason is that the threat has fundamentally changed. AI-generated phishing has erased the visual and linguistic tells that awareness programs teach employees to spot. There are no more suspicious typos, no awkward phrasing, no generic “Dear Customer” salutations. Modern lures arrive with plausible sender names, contextually accurate references drawn from the target’s LinkedIn profile or company news, and writing quality indistinguishable from legitimate internal communications. FBI alerts from 2026 document nation-state actors deploying sophisticated spearphishing techniques, including QR code variants designed to bypass conventional filters entirely. Training programs built around yesterday’s signals cannot defend against today’s lures.
Human error drives a significant share of breaches not because employees are careless, but because the cognitive demand being placed on them is unrealistic. Asking every person in an organization to correctly identify a sophisticated, contextually tailored lure, every time, across hundreds of emails per week, is not a training problem. It is a system design problem.
The ROI picture for simulation-based programs reflects this. Practitioner experience consistently shows that organizations running phishing simulation programs for three or more years see click rates plateau rather than trend toward zero. The marginal return on additional training investment diminishes as attacker sophistication rises faster than behavioral conditioning can adapt.
The deeper issue is a category error in how security leaders have framed the problem. Training modifies behavior probabilistically; training can improve detection rates at the margins, but it cannot achieve certainty. Technical controls fail attacks deterministically; an origin-bound credential cannot be replayed on a spoofed domain, regardless of whether the employee clicked. Cybersecurity threats and solutions have evolved asymmetrically: attackers invest in bypassing the human layer, while defenders have continued investing in strengthening it. Mid-market organizations need to shift toward controls that succeed independent of human judgment.
What ‘Phishing-Resistant’ Actually Means
“Phishing-resistant” is not a marketing claim. It has a specific technical definition that regulators and standards bodies have codified: an authentication mechanism is phishing-resistant if a credential cannot be intercepted and replayed by an adversary controlling a fake site or a man-in-the-browser proxy.
Most deployed MFA fails that test. SMS one-time codes, push notification approvals, and TOTP authenticator apps are all bypassable in real time. A phishing proxy sits between the victim and the legitimate site, relays the credential, triggers the MFA prompt on the real service, captures the code the victim enters, and forwards it before it expires. The employee completed every step correctly and the account is still compromised. This is not an edge-case attack; credential-phishing kits with built-in proxy capability have been widely documented by threat intelligence researchers.
FIDO2 and passkeys close this gap at the protocol level. The cryptographic challenge-response is bound to the legitimate origin domain at the hardware or platform layer during credential registration. A passkey enrolled at login.company.com will not respond to a challenge from login.company-verify.com. The binding is enforced by the authenticator itself, not by the user’s ability to spot a spoofed URL. There is no code to intercept, no prompt to relay.
The regulatory implications are now concrete. FFIEC guidance has established MFA as a core safety and soundness requirement, and regulators have increasingly signalled that legacy factors require a documented improvement roadmap, a trajectory that CISA’s explicit designation of SMS, push, and OTP factors as phishing-susceptible makes difficult to ignore. That requirement is beginning to cascade into vendor contracts across mid-market sectors beyond financial services, an emerging trend rather than a settled standard.
For security leaders building an internal case, the reframe is simple: the question is not whether employees have MFA, but whether the MFA they have can be bypassed by a proxy kit running on commodity infrastructure. For most mid-market organizations today, the honest answer is yes.
The Three-Layer Control Stack for Mid-Market Organizations
Knowing which MFA factors are phishable is the diagnostic; the three-layer stack below is the prescription.
Mid-market organizations rarely have the budget or staffing to replicate enterprise-scale identity infrastructure, but they do not need to. Three categories of technical control, sequenced by deployment complexity, together close the majority of phishing exposure:
- FIDO2 and passkeys eliminate credential replay (as detailed in the next section)
- Email authentication (SPF, DKIM, DMARC) prevents domain impersonation and spoofed-sender attacks at the mail-server level, before a lure ever reaches an inbox
- Adaptive MFA applies risk-scored friction at login, raising the cost of account takeover even when credentials are partially compromised
Each layer targets a distinct attack surface, which is why the three together outperform any single control deployed in depth. FIDO2 addresses the authentication layer; email authentication addresses the delivery layer; adaptive MFA addresses the access layer for accounts not yet migrated to FIDO2. Removing one leaves a gap the others cannot fully compensate for. This is a cybersecurity risk mitigation stack with interdependencies, not a checklist where any item can be deferred indefinitely.
Before allocating new budget, security leaders should audit what is already deployed. Many mid-market organizations have SPF records configured on their primary domain but no DMARC policy, or have legacy push-notification MFA that can be upgraded to phishing-resistant factors within the same identity provider. Identifying those partial deployments first determines whether the next step is a new purchase or a configuration change, which materially affects both cost and rollout timeline. Subsequent sections address each layer in full.
Layer One: FIDO2, Passkeys, and Hardware Keys
FIDO2 is the umbrella standard beneath all phishing-resistant authentication. It combines WebAuthn (the W3C browser API that handles credential creation and assertion) with CTAP2 (the protocol connecting external authenticators to devices). Passkeys are the consumer-facing implementation: FIDO2 credentials that sync across devices through platform ecosystems, making them portable without sacrificing the origin-bound cryptographic property that eliminates phishing replay.
Hardware Keys vs. Passkeys: Matching the Tool to the Risk
Hardware security keys represent the strongest available form of FIDO2 authentication. The private key is generated on-device and never exported, making it impossible to phish, extract via malware, or replicate. That property makes hardware keys the correct choice for IT administrators, privileged accounts, and finance roles with wire transfer authority, regardless of what broader deployment looks like. Two physical keys per user (primary plus backup) is the operational minimum.
Passkeys trade the non-exportability guarantee for deployment scale. For general workforce accounts, that tradeoff is appropriate. Passkeys enroll through existing device ecosystems and integrate natively with major identity providers, removing the hardware distribution bottleneck that has historically stalled FIDO2 adoption in mid-market environments. Organizations working through a mid-market deployment context will typically find passkeys are the realistic path to broad FIDO2 coverage without proportionally large procurement cycles.
Deployment Order and Integration Friction
The tiered sequence for mid-market organizations: hardware keys to privileged and administrative accounts first, passkeys to the general workforce through the SSO layer second, and a defined retirement date for SMS and TOTP factors rather than an open-ended coexistence. Leaving legacy factors active indefinitely preserves the attack surface FIDO2 is meant to close.
Three integration friction points require resolution before rollout begins. Legacy VPN clients frequently lack FIDO2 support and need either replacement or a modern authentication proxy. On-premises applications authenticating directly against Active Directory without modern authentication extensions cannot consume FIDO2 credentials natively. Help desk credential recovery workflows must be redesigned around backup authenticators or recovery codes stored in a privileged access management system, not knowledge-based verification.
When authentication is origin-bound, credential phishing kits, adversary-in-the-middle proxies, and session token theft stop producing usable credentials. That is the deterministic outcome this layer delivers.
Layer Two: Email Authentication — DMARC, SPF, and DKIM
While FIDO2 secures the authentication layer, it does not address the attack surface that delivers phishing attempts in the first place. Email authentication closes that gap.
SPF (Sender Policy Framework) authorizes specific mail servers to send on behalf of your domain via a DNS TXT record. A correctly configured SPF record blocks external actors from spoofing your domain through unauthorized infrastructure. Two limitations matter: SPF does not survive forwarded messages, and subdomains without their own SPF records remain unprotected regardless of the primary domain’s configuration.
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outbound messages. Receiving mail servers verify the signature against a public key published in DNS, confirming the message was not altered in transit and originated from an authorized system. This integrity layer addresses what SPF cannot; SPF validates the sending server’s IP, but DKIM validates the message itself.
DMARC ties both protocols together. Per RFC 9989, the current DMARC core specification, DMARC requires that the domain passing SPF or DKIM be aligned with the visible From address, then instructs receiving servers what to do when that alignment fails: monitor (p=none), quarantine, or reject. DMARC also generates aggregate and forensic reports, giving your organization direct visibility into who is sending email that claims to be from your domain.
The policy progression is not optional. Move directly to p=reject without a monitoring period and you will likely drop legitimate mail from overlooked sending sources, such as marketing platforms, HR systems, or third-party integrations. A phased approach, beginning at p=none, advancing to p=quarantine once reporting confirms all authorized senders are covered, and only then moving to p=reject, is the reliable path to full enforcement without operational disruption.
Subdomain coverage is the gap most mid-market organizations miss. A primary domain at p=reject remains exploitable if hr.company.com or mail.company.com lack their own SPF and DMARC records. The sp= subdomain policy tag in DMARC addresses this by extending the primary domain policy to subdomains explicitly.
From a cybersecurity risk mitigation standpoint, email authentication delivers dual-direction protection: it prevents spoofed emails from reaching employees and prevents your domain from being weaponized in campaigns targeting others. Critically, deployment requires no endpoint changes and no user enrollment, making it one of the highest-ROI controls available to mid-market organizations at any stage of their security maturity.
Layer Three: Adaptive MFA and Risk-Based Access Controls
Adaptive MFA evaluates contextual signals at the moment of each login attempt and adjusts the required verification step based on assessed risk. The signals that feed this evaluation typically include device posture (managed vs. unmanaged), geolocation, network origin (corporate, residential, or anonymizing proxy), time of access, and behavioral baselines established for that specific account. No single signal triggers a decision; the platform synthesizes them into a risk score.
The scoring logic is consistent across implementations even when vendor methodologies differ. A login from a known managed device on the corporate network during business hours scores low risk and may clear with a passkey or biometric alone. The same credential attempting access from an unfamiliar country at 2am through a residential proxy scores high risk and should trigger step-up authentication or hold the session pending review. The control does not rely on the user to notice anything suspicious; it acts on the context regardless of user awareness.
For mid-market organizations mid-way through a FIDO2 rollout, adaptive MFA is the most practical compensating control available. Legacy applications that cannot yet accept FIDO2 credentials remain exposed during the transition period; adaptive MFA raises the cost of account takeover on those accounts without waiting for full migration to complete.
Evaluating platforms for mid-market fit requires three non-negotiable criteria. First, native integration with the existing identity provider, so risk policies apply consistently across SSO-connected applications. Second, API access for SIEM alerting on high-risk authentication events, so suspicious login attempts surface as actionable alerts rather than silent log entries. Third, device compliance checking that does not require universal MDM enrollment, since partial MDM coverage is the norm in mid-market environments, not the exception.
Cybersecurity risk mitigation through this layer is directly measurable. Track high-risk authentication events blocked or stepped up per week, the reduction in account compromise tickets after deployment, and the percentage of authentication completions that used no phishable factor. These three metrics, documented in a structured IT security risk management framework, translate control activity into language that resonates with leadership and validates the investment.
How to Prioritize Deployment Order for Mid-Market Realities
With the three control layers defined, sequencing determines whether deployment delivers risk reduction on a realistic timeline or stalls under operational friction.
Phase one is driven by blast radius, not convenience. IT administrators, finance teams, and executive accounts should receive FIDO2 hardware keys before any broader rollout begins. These accounts are the primary targets of spear-phishing and business email compromise precisely because compromising one grants lateral movement, wire transfer authority, or administrative access to identity infrastructure. The deployment complexity is low at this scale; the risk reduction is immediate and disproportionate.
Email authentication runs in parallel with phase one, not after it. SPF, DKIM, and DMARC at p=none require no end-user enrollment and no endpoint changes. They are DNS and mail infrastructure configurations. Starting DMARC in monitoring mode during this phase is strategically valuable because aggregate reporting frequently surfaces active spoofing campaigns that organizations did not know existed. That intelligence also strengthens the internal business case for accelerating the broader rollout.
Phase two extends passkeys to the general workforce through the SSO layer, retires SMS-based MFA for all cloud application access, and advances DMARC policy to p=quarantine using the reporting data collected in phase one. Moving DMARC to p=quarantine before reviewing that data is a common mistake that causes legitimate mail to be dropped and triggers rollbacks that set the program back months.
Phase three handles the harder problems: legacy VPN modernization, on-premises application authentication, and DMARC p=reject with subdomain coverage. These require vendor negotiations and longer change management cycles. They should carry defined completion dates, not open-ended backlog status.
For organizations in financial services, healthcare, or the defense supply chain, regulatory timelines add a forcing function. FFIEC guidance makes clear that authentication controls previously shown effective no longer provide sufficient defense, creating a strong regulatory impetus for a documented modernization roadmap, a dynamic that accelerates the internal business case beyond what a risk argument alone typically achieves.
Sequencing is where most mid-market deployments succeed or stall. For a broader view of the cybersecurity technologies mid-market organizations need to close the gap with larger enterprises, the prioritization logic applies across the full control stack. HecateLabs works with mid-market security teams to build sequenced roadmaps that account for tech stack constraints, compliance timelines, and change management capacity, producing a defensible, achievable plan rather than a theoretical ideal.
Measuring Phishing Exposure Reduction: KPIs That Actually Matter
Deploying the control stack is half the work. Knowing whether it is reducing exposure requires a measurement framework that tracks technical outcomes, not proxy behaviors.
Phishing-resistant factor coverage is the primary deployment metric. Track the percentage of authentication events completed with a phishing-resistant factor, segmented by application, user population, and account privilege level. Organization-wide averages routinely mask dangerous gaps: a 70% coverage rate looks acceptable until the breakdown reveals that finance and IT administrator accounts still authenticate via SMS. Segment the data, and gaps in high-risk account tiers become actionable priorities rather than statistical noise. Research confirms this blind spot: systematic reviews of MFA compliance find that even payment systems, among the most scrutinized environments, fall short of full NIST 800-63B alignment, illustrating why averages obscure real exposure. For a broader view of how these metrics fit into an integrated cyber security risk mitigation strategies framework, that resource maps controls to measurable outcomes across mid-market environments.
DMARC aggregate reports provide a direct measure of domain impersonation volume. The count of emails failing DMARC authentication before and after p=reject enforcement quantifies how much spoofed mail was reaching potential recipients. That before-and-after delta is a concrete deliverable for leadership reporting because it translates a technical control into a visible threat reduction number.
Account compromise rate, measured as confirmed account takeover incidents or credential stuffing alerts per quarter, is the outcome metric that connects control deployment to business risk. Establish a baseline before deploying adaptive MFA and FIDO2, then track quarterly for the first two years. Without a pre-deployment baseline, any reduction is anecdotal.
Mean time to detect (MTTD) for suspicious authentication events should fall after adaptive MFA deployment, because high-risk login attempts now generate alerts that previously did not exist. If MTTD is not improving, the SIEM integration or alert tuning requires immediate attention.
Finally, do not use phishing simulation click rates as the primary measure of technical control effectiveness. Click rates measure training program performance. Conflating them with control stack metrics obscures whether the technical layer is actually blocking attacks, which is the only question that matters here.
Addressing the Most Common Implementation Objections
Even security leaders who accept the control stack on its merits face internal resistance before a single hardware key ships. Each objection below has a direct answer.
“Hardware keys for everyone are too expensive.” Reserve hardware keys for privileged accounts, IT administrators, and finance roles with payment authority; deploy platform passkeys for the general workforce through the existing SSO layer. Hardware spend drops sharply while the highest-risk accounts retain the strongest protection. Email authentication operates at the DNS and infrastructure layer, keeping per-user cost at zero.
“Our legacy ERP and on-premises applications can’t support FIDO2.” Place those systems behind an application proxy or identity gateway that enforces modern authentication at the perimeter. The legacy application never needs to change; the gateway handles the FIDO2 handshake. This preserves phishing-resistant authentication for accounts that access those systems without waiting for a vendor patch that may never arrive.
“Our employees won’t adopt it.” Passkeys integrated into an existing SSO flow eliminate the manual code-entry step that makes OTP-based MFA burdensome. Enrollment rates improve when deployment is framed as a convenience upgrade rather than a compliance mandate. The friction argument weakens once users experience biometric or device-tap authentication against hunting for a six-digit code.
“Our help desk can’t absorb FIDO2 recovery requests.” Credential recovery is solvable with a defined backup authenticator registered at enrollment and recovery codes stored in a privileged access management solution built for mid-market operational realities. A well-configured identity provider resolves most recovery scenarios without opening a social engineering vector that would undermine the control.
“We already have MFA.” This is the objection that matters most. CISA is explicit: SMS codes, push notifications, and TOTP authenticator apps are phishing-susceptible because a real-time adversary-in-the-middle proxy can relay and consume them before they expire. Having MFA deployed is not the same as having phishing-resistant authentication. Regulators, the cyber insurance market is moving in this direction, and enterprise customers increasingly recognize this distinction, organizations whose MFA posture consists entirely of push notifications are increasingly exposed to that scrutiny.
The Regulatory and Insurance Landscape Is Forcing the Issue
Financial regulators have made phishing-resistant MFA an examination priority. FFIEC guidance requires financial institutions to conduct periodic risk assessments and deploy MFA or controls of equivalent strength, a standard that legacy SMS and push-based factors increasingly struggle to meet as the threat environment evolves. Mid-market financial institutions without a documented modernization roadmap face examination findings with attached remediation timelines, not a polite suggestion to improve.
Cyber insurers have scrutinized MFA posture at underwriting. Cyber insurers have increasingly scrutinized MFA posture at underwriting; organizations should consult their broker about how authenticator type is treated in their specific policy.
The cascade extends beyond financial services. As regulated anchor customers strengthen their own authentication posture, downstream vendor assessments are likely to reflect the same standards over time.
For security leaders building internal business cases, this convergence reframes the investment entirely. FIDO2 deployment and email authentication are no longer discretionary risk-reduction initiatives; they are increasingly prerequisites for maintaining existing customer relationships and preserving insurance coverage terms. Presenting the project in those terms, rather than as a pure security improvement, shortens the leadership approval cycle considerably.
Building a Phishing-Resistant Posture That Holds
The regulatory and insurance pressures in the previous section crystallise a simpler underlying principle: technical controls fail phishing attacks deterministically, while training only reduces the probability of a mistake.
The phased deployment order described above, privileged accounts first, general workforce second, legacy integrations third, remains the practical path for mid-market organizations to reach full coverage without stalling on operational friction.
The three core metrics, phishing-resistant factor coverage, DMARC aggregate report deltas, and quarterly account compromise rate, translate control deployment into terms leadership can evaluate.
Organizations that deploy proactively carry a defensible posture into examiner reviews, insurance renewals, and vendor security assessments. Those that wait react to findings instead, which compresses timelines and reduces leverage in negotiations with insurers and customers.
HecateLabs partners with mid-market security leaders to assess current control gaps, build phased deployment roadmaps, and measure exposure reduction over time. Organizations ready to move beyond awareness training as a primary defense can begin with a control gap assessment against the three-layer framework described throughout this post. The path from phishing-susceptible to phishing-resistant is sequenced, measurable, and achievable within mid-market operational reality.
Conclusion
Phishing-resistant technical controls outperform awareness training because they remove the human error variable entirely rather than trying to minimize it. The three-layer framework, built on FIDO2 authentication, hardened email infrastructure, and adaptive access controls, gives mid-market organizations a structured, sequenced path to measurable exposure reduction. Deployment order matters, and proactive organizations enter regulatory reviews and insurance renewals with defensible evidence rather than reactive explanations.
The metrics are clear, the technology is available, and the regulatory pressure is already building. Waiting only narrows your options.
