Yes, if the workflow depends on human-selected addresses. A separate confirmation step is a compensating control for identity-by-appearance problems, especially when the same interface can be manipulated by dusting or nested object injection. The second channel should confirm the exact recipient and not just the amount, otherwise the attacker can still win on trust.
Why a Separate Confirmation Step Helps When the Recipient Is Chosen in the Interface
A second confirmation step is most useful when the sending workflow lets a person select or approve an address inside the same interface that can be influenced by spoofing, display manipulation, or object substitution. The control should validate the exact recipient identifier, not just the amount or destination label, because the practical risk is trust in appearance rather than trust in the underlying transaction data.
That distinction matters most where the user is making a high-value decision under time pressure. If the confirmation screen reuses the same manipulated view, it can reassure the operator while preserving the attacker’s altered recipient choice. A good confirmation step therefore forces a fresh check of the concrete transfer target before execution.
It is also worth separating “confirmation” from “friction.” A confirmation step that merely adds another click without re-evaluating the recipient gives a false sense of control. The useful design pattern is independent verification of the address or account that will actually receive the funds.
When the Second Channel Should and Should Not Be Treated as a Control
Use the extra step when the transfer path depends on human review, shared admin tooling, or a wallet or payment interface that can be influenced by manipulated data, cached selections, or deceptive UI elements. In those cases, the control reduces the chance that a user approves a transfer to the wrong destination because the interface looked legitimate.
Do not rely on it as the only safeguard when the transfer process is fully automated, when recipient addresses are machine-validated against an allowlist, or when the workflow already binds approval to an immutable transaction object. In those cases, the stronger control is not a second human look, but a design that makes recipient substitution impossible or immediately detectable.
The control is also strongest when the confirmation uses a different trust path from the initiating screen. For example, a second channel can require the user to verify the recipient using a separate device, separate session, or out-of-band approval record, which makes it harder for a single UI compromise to carry through.
What Good Confirmation Design Should Verify
A worthwhile confirmation step should present the exact recipient, the amount, and any material transfer metadata in a form that cannot be silently rewritten by the same interface state. It should be obvious whether the user is confirming a new payee, a previously trusted destination, or a modified destination that deserves extra scrutiny.
For large transfers, the confirmation should also surface the reason the destination is considered trusted. If that trust comes from an address book, allowlist, or prior approval, the system should make the basis explicit so that users can detect when an apparently familiar destination is actually a changed or newly added object.
Where the workflow permits it, the confirmation can also display the first and last characters of the address, a unique recipient label, and a warning when the destination has never been used before. Those details do not replace secure transaction binding, but they help humans spot when the transfer target has been swapped or disguised.
Risk and Threat Considerations
The main risk is that a transfer approval process can be fooled by what the operator sees instead of what the system will execute. Attackers that can manipulate the displayed recipient, substitute an object reference, or reuse a trusted-looking entry can steer a large transfer to the wrong destination even when the amount is acknowledged correctly.
Failure mechanism: The approval step validates the wrong thing, such as the amount, a friendly label, or a manipulated display object, while the actual recipient remains attacker-controlled.
Impact: Funds can be sent irreversibly to an unintended destination, and the organisation may not notice until the transaction has settled and recovery options are limited.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Recipient confirmation workflows depend on protecting the account or session used to approve transfers. |
| AC-6 — Least Privilege | Large transfers should be constrained so approvers can only authorise the scope they truly need. | |
| Recommendation — Protect approval credentials and rotate them when transfer approval exposure is suspected. Limit transfer approval authority to the smallest necessary set of destinations and limits. | ||
| OWASP ASVS | V8 — Authorization | The question is about ensuring the action truly authorizes the intended recipient, not just the amount. |
| V7 — Session Management | A second confirmation is only trustworthy if the approval session cannot be swapped or replayed. | |
| Recommendation — Bind approval logic to the exact recipient and enforce robust authorization checks. Use strong session binding so the confirm step cannot be replayed or hijacked. | ||
| MITRE ATT&CK | T1566 — Phishing | UI deception and trust abuse can be part of the path that tricks an approver into sending funds elsewhere. |
| Recommendation — Hunt for deceptive user interaction patterns that precede fraudulent transfer approvals. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | High-value approvals benefit from stronger identity assurance for the approver. |
| Recommendation — Require stronger assurance for users who can approve high-value transfers. | ||
Practitioner Guidance
What to verify: Confirm that the second step re-checks the exact recipient object, not a display name, contact entry, or cached UI state. If the approval can be completed without seeing the actual transfer target, the control is too weak for high-value transfers.
Decision rule: If the workflow allows human selection of the recipient, require a separate confirmation that binds the recipient and the amount together; if the destination is fully system-controlled, prioritise immutable recipient binding and allowlists over an extra human prompt.
Common mistake: Treating a second click, modal, or warning banner as security when it does not introduce an independent trust check. That usually adds delay, not resistance to spoofing or substitution.
Practitioner takeaway: The value of a separate confirmation step is not the extra prompt itself, it is whether the organisation can force an independent check of the exact recipient before an irreversible transfer leaves the system.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org