Magic Link File Sharing for Construction: Security FAQ

Token entropy. Link expiry. Revocation. Audit trail. The honest answers about how secure a no-login magic-link share actually is for jobsite info.

Every GC who tries SubShare for the first time asks the same question: is a no-login link really secure enough for blueprints, lockbox codes, and the customer's home address?

It's a fair question. Here are the honest answers — about how the tokens work, what an attacker would have to do, what insurance carriers care about, and where the model has real limitations.

How much entropy is in a magic link?

A well-implemented magic link uses a cryptographically random token of at least 128 bits (16 bytes), URL-safe-encoded. That is roughly 22 characters of random URL-safe text. The guess space is 2¹²⁸, which is mathematically indistinguishable from a properly-hashed password from a brute-force standpoint.

Compare this to a typical user-chosen password: 8–10 characters, mostly lowercase, often a real word with a "1!" at the end. Practical entropy of a real-world password is closer to 30–40 bits. Magic links are not the weak link.

What about link interception?

The link is delivered over SMS. SMS is unencrypted at the carrier level — in theory, a carrier-level intercept could read it. In practice this is the same threat model as texting the lockbox code in plain SMS today, which most GCs do already.

The big improvement is what the intercept actually gets you: with the link, the attacker still has to use it before you revoke it, and you'll see the unfamiliar access in the audit log. With the plain SMS code, the attacker holds the code forever.

Per-recipient scoping

A good magic-link system issues a separate link per recipient. If you invite 6 subs, you generate 6 links. This matters for two reasons:

1.Revocation is granular. Firing one sub doesn't affect the others.
2.Forwarding is traceable. If a link gets used from a device you don't recognize, you know which sub forwarded it.

Expiry

Most GCs configure links to expire when the job closes. Some keep them open through the warranty period so the sub can re-reference specs months later. The right answer depends on whether you need the sub to be able to see the plans during warranty work — if yes, set a longer expiry. If no, expire at substantial completion.

Either way, expiry should be a setting, not a hard-coded default — the right value differs per trade.

Audit log

A magic-link system without an audit log is half a system. The log should show, at minimum:

When the link was first opened.
How many distinct devices used it.
Which files within the project were viewed.
When the link was revoked, and by whom.

For most residential and light commercial work this satisfies insurance and contract documentation requirements. For regulated work (healthcare facilities, government contracts) confirm with your compliance contact before relying on a magic-link system alone.

Where the model has real limits

Three places we're honest about:

Device-level theft. If a sub's phone is stolen and unlocked, the attacker sees whatever the sub saw. This is the same threat as any "magic link" pattern (your bank login email, etc.). Mitigation: keep expiry tight on sensitive jobs.
Carrier-level SMS intercept. Very rare in practice but not zero. For government or healthcare jobs, prefer link delivery over email + 2FA instead of SMS.
Social engineering against the GC. If someone phones you pretending to be the new electrician and asks for the link, you might send it. No technical system fixes that.

The bottom line

The short version, in one place: a correctly implemented magic link for construction file sharing is a cryptographically random token of at least 128 bits embedded in a URL — a guess space astronomically larger than the 30–40 bits of practical entropy in a typical user-chosen password (see NIST SP 800-63B). Unlike a password, each link is scoped to one recipient, so revoking a fired subcontractor cuts only that sub's access. Unlike an emailed PDF, access ends when you revoke it instead of living on the sub's device forever. And an audit log records first open, device count, files viewed, and revocation. The genuine residual risks are stolen unlocked phones, rare carrier-level SMS interception, and social engineering against the GC — none of which passwords solve either. For residential and light-commercial construction, that trade favors the link.

Frequently asked

Are magic links really secure if there's no password?

When implemented correctly: yes, and often more so. A long random token in the URL has more entropy than a typical user-chosen password. The key difference is the link is single-use-scoped (per recipient) and instantly revocable, which most passwords are not.

What happens if a sub forwards their link?

The forwarded recipient can use it until you revoke it. Good systems show you which device first opened the link and let you see the access log. If you suspect forwarding, one click cuts the link.

How long do magic links last?

Configurable per project. Most GCs set them to expire when the job closes. Some keep them open for the warranty period so the sub can re-reference the spec.

Is this compliant with my insurance / data retention requirements?

For residential and light commercial in the US, a magic-link system that issues per-recipient tokens and maintains an audit log meets the practical requirements most GC insurance policies care about. For data residency or HIPAA-adjacent work, check the provider's data-handling docs.

Sources & notes

Real-world password entropy of roughly 30–40 bits is consistent with guidance on user-chosen secrets in NIST SP 800-63B.
The 128-bit figure describes a correctly implemented magic-link token; verify any specific vendor's token length and handling before relying on it.
SMS being unencrypted at the carrier level is a general property of the protocol, not specific to any provider.