Recipient verification at the boundary: cutting accidental disclosure by 80%

Of all the ways that sensitive files leave an organization unintentionally, misaddressed transfer links are among the most common and the most underappreciated. Credential-based attacks get the attention — phishing, credential stuffing, token theft — because they involve an adversary doing something deliberate. The misaddressed link requires no adversary. The sender makes a mistake. The file goes to the wrong place. Under HIPAA or NYDFS Part 500, the outcome is the same as a sophisticated attack: reportable incident, investigation, remediation cost.

We’ve been working on this problem systematically for the past 18 months. This post describes what we built, the philosophy behind it, and how we measure the impact.

The misaddressed-link problem

The problem is more dimensional than it appears. “Sent to the wrong email address” is the obvious case, but it’s only one of several patterns.

Autofill collision. The sender starts typing a recipient email address. Their email client or browser autofills a suggestion. The suggestion is a similarly-named contact — not the intended recipient — and the sender accepts it without confirming. This is the most common mechanism. Autofill is convenient precisely because it reduces cognitive friction, which also reduces the friction of accepting the wrong suggestion.

Name/role confusion. In large organizations, multiple people share similar names or roles. “Send this to the Sarah in Finance” resolves differently to different senders. Transfer links generated without specific identity verification land in whichever Sarah’s inbox appears first in the sender’s contact list.

Stale contact information. The sender has a correct email address for the intended recipient, but the recipient’s email address changed. The link goes to a former email address that may now be unmonitored, reassigned to a new employee at the same domain, or forwarded to an unexpected destination.

Forwarding by recipient. The intended recipient correctly receives the link but forwards it — to a colleague, to their personal email, to a shared inbox — without recognizing that the link carries access authorization. The file was sent correctly in the first hop; unauthorized access happens in the subsequent hop.

Domain confusion. The sender intends to send to a recipient at company-name.com but sends to company-name.co (a different domain that may resolve to a different organization or may be a typo-squatting domain specifically registered to receive misdirected email from the primary domain).

Each of these failure modes has different characteristics, and a comprehensive solution addresses all of them rather than just the most obvious one.

Our boundary-verification model

We call our approach boundary verification. The core idea is that the access authorization for a transfer link should not be finalized at send time based solely on the sender’s input. It should be confirmed at the point where the link reaches a recipient who must verify their identity before the file becomes accessible.

The architectural components:

Sender-time domain vetting. When a sender enters a recipient email address, we perform real-time domain validation: is the destination domain active? Does its MX record suggest it’s a functional mail domain? Has SEND-SECURELY.COM previously delivered to this domain? Does the domain match any known typo-squatting patterns against the sender’s organizational contacts? This catches domain confusion and stale domain errors at send time, before the link is generated.

Recipient authentication requirement. Transfer links in boundary-verification mode do not grant file access on click. They initiate a recipient authentication flow. The recipient must authenticate their identity — via email OTP, SMS OTP, or FIDO2 passkey if previously registered — before the file becomes accessible. The authentication is bound to the email address the link was sent to: a recipient who receives a forwarded link and authenticates with a different identity than the link was addressed to triggers a mismatch alert.

Identity assurance level configuration. We allow senders and workspace administrators to configure the identity assurance level required for different transfer contexts, aligned with NIST 800-63 IAL/AAL tiers. Standard transfers might require IAL1 (self-asserted identity via email OTP). Transfers involving PHI or CUI might require IAL2 (identity proofed against an authoritative source) or AAL2 (phishing-resistant MFA). The configuration is contextual — higher assurance for higher sensitivity, less friction for routine transfers.

Post-delivery mismatch detection. For cases where the link correctly reached the intended recipient but was subsequently forwarded, we detect access attempts where the authenticating identity differs from the addressed identity. These trigger an alert to the sender and optionally suspend access pending manual review.

Delivery confirmation with recipient fingerprint. After successful authenticated access, we generate a delivery receipt that includes: the authenticated recipient identity, the timestamp of access, the identity assurance level used, and a partial fingerprint of the accessing client. This receipt is available in the sender’s audit log and can be included in compliance evidence packages.

The 80% number — methodology

We tracked accidental-disclosure incidents across our customer base in two populations: workspaces with boundary verification enabled and workspaces without, matched for industry, transfer volume, and workspace size.

We define an accidental-disclosure incident as: a transfer link access event where the authenticated accessing identity differs from the intended recipient identity documented in the transfer record. This captures misaddressed sends (the wrong person received the link), forwarding-based unauthorized access (the right person forwarded the link to an unintended recipient), and domain-confusion sends (a link sent to a domain that resolved to the wrong organization).

We do not count in this metric: authentication failures on the correct recipient (failed OTP attempts, which are not disclosures), link expirations before any access (which indicate the link was never used), or access attempts that were blocked by the mismatch detection and never proceeded to file access.

Over a rolling 12-month observation window ending September 2025:

• Workspaces without boundary verification: 2.3 accidental-disclosure incidents per 10,000 transfers
• Workspaces with boundary verification enabled at IAL1 (email OTP): 0.51 incidents per 10,000 transfers
• Workspaces with boundary verification at IAL2 or above: 0.14 incidents per 10,000 transfers

The 80% figure represents the reduction from the no-verification baseline to the IAL1 baseline: 2.3 to 0.51 incidents per 10,000 transfers is an 78% reduction, which we round to 80% in our headline.

At IAL2 or above, the reduction is 94%. The IAL2 population is smaller — it’s primarily HIPAA covered entity customers with mandatory high-assurance verification — so we use the IAL1 number as the more representative baseline for the headline.

What the residual 20% looks like. The remaining incidents at IAL1 are almost entirely in two categories: (1) cases where the sender provided an incorrect email address that does happen to belong to a real authenticated user — a colleague with a similar name who successfully authenticates with their own identity, which creates an authorized access event for the wrong person; and (2) forwarding cases where the original recipient authenticates on behalf of forwarding the link to a colleague, effectively authorizing the access manually. Both of these are significantly harder to eliminate without creating prohibitive friction in legitimate workflows.

Configuration patterns

Baseline configuration. Enable boundary verification at IAL1 for all external recipient transfers. This requires a one-time email OTP confirmation from the recipient before access. Recipient friction is low — one additional click and an OTP entry. Detection coverage is high for misaddressed sends and forwarding-based access.

High-sensitivity configuration. For workspaces handling PHI, CUI, or other high-sensitivity categories, configure IAL2 for external recipients. IAL2 requires that the recipient be registered in our identity-proofed recipient directory or complete an identity proofing flow at first access. For recurring transfer relationships (the same provider always receiving from the same source organization), identity proofing amortizes across many transfers after the initial setup.

Organizational whitelist. For internal transfers between verified members of the same organization, boundary verification can be configured at a lower assurance level or suppressed entirely for organizational domains on an allowlist. Intra-organizational transfers carry lower misaddress risk because the sender and recipient share organizational identity infrastructure.

Alert routing. Mismatch detection alerts can be routed to the sender alone, to the workspace security team, or to a configured SIEM endpoint. For regulated workspaces, routing mismatch alerts to the security team ensures that potential disclosure incidents are visible beyond the individual sender.

The accidental-disclosure surface in file transfer is persistent and underestimated. Most security investments focus on the external adversary; boundary verification addresses the internal human element. The 80% reduction we measure is significant and achievable with minimal friction — email OTP at the delivery boundary is a one-step process that most recipients accept without complaint.