Look for uneven enrollment, low repeat use, confusion during setup, and users who still rely on passwords or OTP codes after security keys are available. If the highest-risk group cannot consistently use the control, the programme has a coverage problem rather than a technology problem.
When phishing protection is missing the audience it was meant to reach
The clearest signal is not a failed login or a blocked attack, it is uneven adoption. If one team, region, role, or device population is consistently underrepresented, the programme is probably optimised for convenience users rather than the people most exposed to phishing. That gap often appears first in onboarding friction, fallback authentication habits, and low repeat use after the initial rollout.
A second warning sign is behaviour that contradicts the control design. If users keep defaulting to passwords, SMS, or one-time codes after phishing-resistant options are available, the programme may be technically deployed but operationally invisible to the intended audience. Coverage is only real when the right users can complete enrolment, remember the workflow, and use the stronger method under normal work pressure.
Programme reach should be judged by actual usage patterns, not by distribution counts. A broad launch that produces thin adoption in high-risk groups is a coverage problem, because the control never becomes the practical default for the users who most need it.
Why coverage fails even when the technology works
Phishing protection often fails at the last mile: communication, enrolment, and exception handling. Security teams may pick a strong control, but if the user journey is too brittle, the help desk too slow, or the fallback path too easy, people will route around the protection. That creates a gap between policy intent and everyday practice.
This is especially visible where authentication choices are constrained by device compatibility, legacy workflows, or business exceptions. NIST SP 800-63 Digital Identity Guidelines is useful here because phishing-resistant authenticators only matter when the enrolment and authentication experience is usable enough for the intended population. The same pattern shows up in access-control programmes more broadly: the control can be sound while the rollout is not.
Look for cohorts that are forced onto weaker fallback methods, because those groups reveal where the programme is losing reach. If the people most likely to receive phishing attempts are also the people most likely to remain on weaker factors, the rollout has not yet converted security intent into actual coverage.
Dropbox GitHub breach 2022 is a good reminder that phishing exposure becomes more damaging when it reaches the wrong account class, because a single compromised workflow account can expose far more than a normal user session. CoPhish OAuth phishing via Copilot Studio shows the same principle in a newer form: if the target audience is not the one the control was designed for, attackers can still harvest tokens or consent in the path of least resistance.
What the user signals usually tell you
Uneven enrollment usually means the rollout depends on local champions, ad hoc support, or a best-effort communications plan. Low repeat use suggests the workflow is too awkward, the benefit is not understood, or users are encountering friction only after the first successful login. Confusion during setup is often the strongest indicator that the programme was designed from a control perspective, not from the user journey backwards.
Repeated fallback to passwords or OTP codes is the most actionable sign, because it shows where users are escaping the intended phishing-resistant path. Ledger Connect Kit npm compromise 2023 and EmeraldWhale Git config credential theft both illustrate how attacker success grows when the control surface leaves alternative access paths or exposed secrets in play. The practical lesson is that coverage failures usually show up as control substitution, not outright refusal.
If security keys are available but users still do not move to them, the issue is usually not awareness alone. It is more often a mix of provisioning friction, device constraints, weak manager support, and exception handling that silently preserves the old habit. That is why coverage reviews should segment by role, device type, location, and support queue, not just by overall adoption.
Risk and Threat Considerations
When the programme misses the right users, the organisation keeps its highest-risk population on the most phishable method. That creates a residual exposure where the control exists in policy but not in practice, which is exactly where attackers look for the easiest account path.
Failure mechanism: users fall back to passwords, OTPs, or shared exception paths because enrolment, support, or device compatibility makes the preferred control harder to use than the weaker one.
Impact: the organisation preserves a predictable phishing and account-takeover path for the very users whose compromise would cause the most damage, while reporting a rollout that appears broader than it really is.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Phishing-resistant authentication must be usable by the intended users. |
| Recommendation — Design enrolment and authentication flows so high-risk users can actually adopt phishing-resistant methods. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | User authentication coverage and fallback use determine whether the control reaches staff accounts. |
| IA-5 — Authenticator Management | Repeated fallback to passwords or OTPs signals weak authenticator lifecycle and adoption issues. | |
| IA-9 — Service Identification and Authentication | Where phishing protection extends to machine or service access, strong auth coverage still matters. | |
| Recommendation — Verify that organizational users are enrolled in the intended strong-authentication path. Review authenticator lifecycle and remove weak fallback paths that keep users on less secure methods. Ensure non-user access paths do not preserve weak authentication as a bypass route. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Coverage defects often appear as inconsistent access method adoption and exception handling. |
| Recommendation — Tighten access paths so the preferred strong control becomes the normal route. | ||
Practitioner Guidance
What to verify: Measure adoption by risk cohort, not by enterprise average. A healthy programme shows the highest-risk users completing setup, using the control repeatedly, and rarely needing fallback methods.
Common mistake: treating enrolment completion as success. Completion only proves the user passed through the process once; it does not prove the control is the normal access path under real working conditions.
Decision rule: If the control is available but users still prefer weaker authentication, treat that as a coverage defect and fix the user journey before assuming the technology needs replacement.
Practitioner takeaway: The real test is whether the intended users adopt the stronger path without friction, exceptions, or quiet workarounds, because a phishing control that is hard to reach is still an exposed population.
Related resources from NHI Mgmt Group
- Who is accountable when a password programme leaves users exposed to phishing and weak credential reuse?
- What are the signs that a fintech authentication program is not covering the right users?
- What are the signs that a HIPAA data protection programme is not working well?
- What are the signs that an MFA programme is not covering the right access scenarios?