How long a password link should last, and how many views

How long should a password link last? As long as the recipient needs to open it, and no longer. For most handovers that means one view and an expiry between one hour and one day: an hour if they’re waiting for it, a day if they’re in another time zone or in meetings. Go to three days only for someone who genuinely won’t see it sooner, and don’t go past a week.

The two settings do different jobs. The view limit decides who gets to read the secret. The expiry decides how long an unread link stays dangerous. Get the view limit right first.

One view does most of the work

A link with one view gives you something no other way of sending a password does: you find out if it was intercepted. If someone else opens it first, your recipient gets a page saying it has already been viewed, tells you, and you change the password. With two or more views, an interceptor and the recipient can both read it and nobody notices.

That’s why a higher view count is rarely a convenience worth having. If three people need the same password, send three links. Each person gets their own one-view check, and you can see which of them has opened theirs. In ShareShield, views are counted across everyone who opens a link, including when you email it to several recipients, so a link sent to three people with one view opens only for the first.

The exceptions are low-value secrets with a broad audience, like the guest Wi-Fi password for an event. There, several views and a few days are fine, provided you change the password afterwards.

Expiry is the safety net

Expiry covers the case where nobody opens the link. An unread link in an inbox is a working credential for whoever gets into that inbox later, so it should stop working soon after the recipient could reasonably have used it. Once a one-view link has been opened, its expiry no longer matters: the secret is already gone.

When you pick an expiry, think about the recipient’s day rather than a round number:

• Time zones. One hour is useless if you send it at 5pm London time to someone in Sydney. A day covers any time zone.
• Weekends. A one-day link sent on Friday afternoon expires on Saturday. Either wait until Monday morning, or use three days.
• Out-of-office replies. If the link gets an auto-reply, burn it and send a fresh one when they’re back. A link sitting for two weeks in the inbox of someone on holiday is exactly what expiry is for.
• Their pace, not yours. A client who reads email once a day needs a day, however urgent it feels to you.

Expiry and views by scenario

If something in the table feels too short, the fix is usually to send the link at a better moment, not to make it last longer. And if the recipient needs the credential again next week, a link is the wrong tool: share it through a password manager instead, as how to send a password securely explains.

Burn it early when plans change

An expiry is a maximum, not a commitment. If the contractor’s start is postponed, or you realise you sent the link to the wrong Sam, burn the link and the secret is deleted straight away. ShareShield also gives recipients a burn link, so someone who receives a secret by mistake can destroy it without opening it.

Defaults and limits in ShareShield

New links default to one view and an expiry of 24 hours unless your organisation sets different defaults. The send form offers 1 hour, 1 day, 3 days and 7 days, or a custom number of hours or days. At expiry the secret is deleted, opened or not, files included.

The most each plan allows:

The Free plan’s ceiling of 1 view and 7 days covers every row in the scenario table except the guest Wi-Fi. The higher limits exist for the cases that really are different, such as a secret several people must open over a long project, and plenty of teams won’t need them.

Set it once for the whole team

Individual judgement is good; a default that makes the right choice for people is better. In ShareShield, an organisation owner can set policies for every secret the team sends: a maximum and default expiry, a maximum and default view count, and whether a passcode is required. The send form pre-fills and locks to the policy, and the API rejects anything outside it.

A sensible starting policy for most teams:

• Default views: 1. Maximum views: 1 or 2. Anyone with a real need for more can be the exception that asks.
• Default expiry: 24 hours. Maximum expiry: 7 days. Long enough for a slow client, short enough that nothing lingers.
• Passcodes required if your team routinely sends production or admin credentials, since it forces the second channel.

For onboarding specifically, sharing passwords with new starters has the day-one timing. Writing the policy down also gives you something to show an auditor: control 5.17 of ISO/IEC 27001:2022 Annex A asks for a management process for allocating authentication information, and “every credential we send is one view, at most seven days, enforced by the tool” is a clear answer.