High-assurance file delivery: gating downloads behind hardware authentication

The link is not the reader

Most systems hand out a private file the same way: mint a signed URL, send it, and trust that only the right person clicks. The signature stops a stranger from guessing the address. It says nothing about who opens it. A forwarded message, a shared mailbox, a screenshot in a chat — any of these puts the file in front of someone the sender never chose.

For routine content that gap is fine. For a contract, a cleared personnel record, or controlled unclassified information, it is the whole problem. The question is not "is this link valid" but "is this the person we meant."

Ask the reader to prove it

The fix adds one step before the bytes leave the server: make the recipient prove, with hardware, that they are who the grant names. A security key or a smart card signs a challenge that a password or a copied link cannot. Security people call this phishing-resistant authentication — the credential cannot be typed, guessed, or handed to a fake site, because the proof is a signature bound to the real one.

Two hardware paths cover most needs. FIDO2 and WebAuthn drive a security key or a phone's built-in authenticator. PIV and CAC cards, already issued across government, reach the same result through a card reader. Either way the user does one thing — touch a key, tap a card — and the server learns that the touch happened.

The shape of the control

The pattern joins two parts that each work well on their own.

First, a signed, expiring URL. It carries who the file is for, when the grant dies, how many times it may be used, and a signature over all of it. On its own this is the familiar model.

Second, a step-up when the link is redeemed. When the browser asks for the file, the server checks the signature and then asks a second question: has this session proven hardware authentication in the last few minutes? If yes, the file streams. If no, the browser goes to prove it and returns to the same link once it has.

The identity provider does the hard cryptography. The file server is a relying party: it reads a signed assertion the provider issues after the ceremony, checks that the assertion clears its bar, and releases the file. It never re-implements the hardware crypto, and it never trusts a claim it did not verify.

Decisions that keep it honest

A control is only as good as its worst case, so design for the worst case first.

Fail closed. If anything is missing — no assertion, a wrong audience, an expired grant, a level below the bar — deny, and offer the step-up. A gate that opens when it is unsure is not a gate.

Short, single-use grants. Tie each link to one use and a few minutes of life. A link that has been spent, or has aged out, is dead: it does not reopen, and it does not leak why it failed.

Bind the grant to a person. Tie the link to the subject it was minted for, and check when it is redeemed that the proven identity matches. A link that escapes then buys the finder nothing, because the file still asks for their key, not the intended reader's.

Trust issuers by name. When more than one group can sign in — staff on one directory, partners on another — trust each source on its own terms, with its own audience and its own required level, and match a token to exactly one of them. No cross-matching, no softer fallback. A token minted for one setting cannot open a file meant for another.

Keep tokens out of the browser. The proof should live in a server-side session and a short-lived signed cookie, not in a value that page scripts can read. A design that parks an access token in browser storage invites the exact theft the hardware key was meant to stop.

Make the strong path the easy path

Security that annoys people gets routed around, so the step-up should cost one touch. A recipient opens the link, the site sends them to their identity provider, they touch the key, and the file downloads. No token to copy, no code to paste, no second app. If they signed in with the same key a moment ago, the session may already clear the bar and the file simply arrives.

The same care applies to failure. An expired link should say, in plain words, that it has expired and to ask for a new one — not drop the reader on a stack trace or a bare error page.

Where it earns its keep

This belongs anywhere the file is worth more than the link. Controlled unclassified information under federal rules. Cleared personnel and contract records. Financial and health data with a named recipient. Board and deal material that must reach one inbox and no other. The standards already point the way: NIST's guidance on authentication assurance, FIPS 201 for PIV, and the FIDO2 and WebAuthn specifications for security keys. The pattern turns those standards into a working gate on the one action that matters — the download.

The short version

A signed link answers "is this address valid." High-value files need the next question answered too: "is this the person." A hardware step-up at the moment of download answers it, fails closed when it cannot, and — built with care — costs the reader a single touch.