Security teams should use ATT&CK as an adversary model, not as the end state. The framework helps map where password-based login is exposed to phishing, account enumeration, and brute force. The practical move is to identify which attack paths depend on passwords and then replace that dependency with challenge-response or mobile-initiated authentication, reducing the attack surface instead of only adding more controls.
Using ATT&CK to identify where passwords create avoidable exposure
ATT&CK is most useful here when teams treat it as a way to trace how password-based authentication is abused in real attack paths. That means looking at techniques such as phishing, credential harvesting, account enumeration, brute force, and post-compromise credential access, then asking which of those paths still exist because a password is still in play.
For passwordless planning, the practical value is not the technique name itself, but the dependency it exposes. If an attack path relies on user-entered secrets, reuse, interception, or replay, the design target should be to remove that dependency, not to layer more compensating controls around it.
That is why ATT&CK works well as an analysis lens for migration planning. It helps security teams compare the current state against the future state and see which techniques disappear when authentication shifts from reusable passwords to stronger challenge-response or device-bound methods.
Map adversary technique to the authentication property you want to eliminate
Teams should translate each relevant ATT&CK technique into a concrete authentication property. For example, phishing pressure points to user-secret entry, brute force points to guessable or rate-limited credentials, and enumeration points to account discovery that feeds later abuse. Once you name the property, you can evaluate whether passwordless removes it or only shifts the problem elsewhere.
That distinction matters because some improvements only harden the password workflow. A better lockout policy, stronger complexity rule, or extra step-up prompt may reduce noise, but it does not remove the core exposure if the attacker can still target a password, a reset flow, or a recovery path. Passwordless improvements should be judged on whether they shrink the attack surface in the paths ATT&CK highlights.
Teams also need to be clear about what still remains attackable after migration. Passwordless can reduce phishing and brute force risk, but it does not automatically solve session theft, social engineering, device compromise, or weak account recovery. ATT&CK is useful precisely because it keeps the analysis grounded in attacker behaviour rather than vendor claims.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1110 — Brute Force | Directly models password guessing and credential attacks against login flows. |
| T1566 — Phishing | Covers credential harvesting techniques that passwordless aims to reduce. | |
| T1087 — Account Discovery | Supports analysis of enumeration paths that often precede password abuse. | |
| Recommendation — Map password exposure to T1110 and remove the guessable credential path with phishing-resistant authentication. Use T1566 to prioritize passwordless for user journeys most exposed to phishing. Harden account discovery and recovery paths that enable later credential attacks. | ||
Practitioner Guidance
What to prioritise: Start with the ATT&CK techniques that are enabled by password entry, password reset, or password reuse, then rank them by how often they appear in your incidents and how much blast radius they create. This usually surfaces the highest-value candidates for passwordless first, especially where an external login path is exposed to phishing or credential stuffing.
What to verify: Confirm that the proposed passwordless design actually removes the password-dependent technique, not just the password field. If a user can still fall back to a password, a recovery code, or a weak help-desk process, the ATT&CK path may still exist even though the primary login screen looks modern.
- Link each targeted technique to a specific control change, such as challenge-response, device binding, or phishing-resistant authentication.
- Test the recovery and enrollment flows with the same ATT&CK mindset as the login flow.
- Measure whether the migration reduces real credential-driven alerts, not only password-reset volume.
Practitioner takeaway: Use ATT&CK to remove attacker-relevant authentication dependencies, not to decorate an unchanged login model with a stronger label. The best passwordless improvement is the one that makes whole classes of password-based techniques unworkable.
Related resources from NHI Mgmt Group
- How should organisations use QR codes in authentication without weakening passwordless security?
- How should security teams use passwordless authentication without weakening PAM?
- How should security teams use MITRE ATT&CK in identity programmes?
- How should security teams use LLMs to map Sigma rules to MITRE ATT&CK?
