How do you know if a confirmation flow is actually phishing resistant?

Why This Matters for Security Teams

A confirmation flow only looks phishing resistant when the approval is cryptographically tied to the live session, the authenticator cannot be copied into another context, and the proof expires before it can be replayed. That distinction matters because attackers rarely need to defeat the whole control; they only need one reusable approval path to forward, relay, or reuse. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that weak identity assurance is usually discovered after impact, not during design.

For practitioners, the mistake is treating any “confirm” button, push notification, or emailed approval link as equivalent to phishing resistance. The control only holds when the confirmation is bound to an enrolled authenticator or equivalent cryptographic proof and evaluated in the same transaction that requested it. Standards such as NIST SP 800-63 Digital Identity Guidelines and NIST SP 800-53 Rev 5 Security and Privacy Controls frame this as assurance, authentication strength, and access control integrity, not user convenience. In practice, many security teams only discover the difference after a relay attack or inbox compromise has already turned “approval” into unauthorized access.

How It Works in Practice

Phishing resistance depends on whether the confirmation flow proves possession of a legitimate authenticator in a way that cannot be forwarded, replayed, or detached from the session. The core idea is simple: the user or approver is not just clicking “yes,” they are producing a cryptographic confirmation that is bound to the origin, challenge, and transaction being approved.

In a strong design, the confirmation step uses an enrolled device, platform authenticator, hardware key, or equivalent cryptographic mechanism. The approval is then checked against the exact session context, often with a short lifetime and a one-time challenge. That is why guidance increasingly favors transaction-specific confirmation over generic step-up prompts. When the attacker captures a link, relays a session, or coerces an approval out of band, the validation should fail because the proof cannot be reused outside the intended context.

• Bind the confirmation to the request, not just the user.
• Use enrolled authenticators with cryptographic proof, not shared secrets.
• Set short TTLs so the approval cannot be replayed later.
• Require the approval to reference the exact action, resource, or scope.

This is especially important in approval workflows that gate privileged access, secret release, payment authorization, admin changes, and agent actions. A useful test is whether the flow still works if the message is forwarded to another mailbox, another device, or another browser session. If it does, the flow is convenience-based, not phishing resistant. The same pattern shows up in real incidents such as CoPhish OAuth Token Theft via Copilot Studio, where the problem is not the existence of a confirmation step, but whether it can be detached from the intended trust boundary. These controls tend to break down in legacy approval chains, email-driven workflows, and cross-device sign-offs because the confirmation is no longer cryptographically bound to the originating session.

Common Variations and Edge Cases

Tighter confirmation controls often increase friction, device-management overhead, and support burden, so organisations have to balance phishing resistance against user accessibility and operational speed. That tradeoff is real, especially where approvers work across multiple endpoints, contractors use unmanaged devices, or emergency actions need rapid execution.

Current guidance suggests treating these cases as design exceptions, not proof that weak approval methods are acceptable. A push prompt alone is not enough if it can be approved from the wrong device or retried indefinitely. A one-time code is not enough if it can be relayed. An emailed approval link is not enough if mailbox compromise or forwarding turns the mailbox into the authenticator. The more the flow relies on a transferable secret or a static channel, the less phishing resistant it becomes.

There is no universal standard for every confirmation pattern yet, especially for hybrid human-to-agent or human-to-human approval chains. For that reason, teams should test three questions: can the proof be replayed, can it be forwarded, and can it be accepted outside the original session. If the answer to any of those is yes, the control may satisfy convenience or auditability, but it does not meet the practical bar for phishing resistance. NIST’s identity guidance and the NHI risk patterns documented by NHI Mgmt Group both point to the same operational rule: if approval is portable, attackers can move it.

Related resources from NHI Mgmt Group

• How do you know if phishing-resistant MFA is actually working?
• How do you know if phishing-resistant authentication is actually reducing risk?
• How do you know if a phishing simulation programme is actually working?
• How do you know if adaptive phishing training is actually working?