A share link for a security document should expire shortly after the review it supports. For a one-off SBOM or report, 7 to 14 days is a sensible default. Use longer windows only for named recipients who sign in, and always make renewal easy so people never ask you to email the file instead.
Why expiry matters for security evidence
An SBOM, a pentest summary or an architecture diagram tells a reader a lot about your environment. The risk is rarely the first reader. It is the link that sits in a mailbox for two years, gets forwarded, and still works long after the document is out of date.
Expiry fixes two problems at once. It limits how long a stray link is useful, and it forces a refresh, so customers see a current document instead of last year's.
What the common platforms actually allow
Limits differ by tool, so check your own settings rather than assuming. Some examples from vendor documentation:
| Tool | What the documentation says |
|---|---|
| Amazon S3 presigned URL | Objects are private by default. The console caps a presigned URL at 12 hours, and the AWS CLI at 7 days. |
| SharePoint and OneDrive | Admins can require Anyone links to expire within a set number of days, and can expire guest access after a set number of days. |
| Google Drive | Adding an expiration date is available only for eligible work or school accounts. |
The practical lesson is that expiry is a setting you must turn on and test. If your tool does not support it for the account type you use, pick a different channel for sensitive files.
A simple decision rule
- One-off review, no account needed: expire in 7 days. If the customer needs more time, send a fresh link.
- Active evaluation with several reviewers: expire in 14 to 30 days, and share with named email addresses instead of an open link.
- Signed customer with ongoing access: use an account based portal with access that you review on a schedule, not a link that never ends.
- Anything containing exploit detail or unpatched findings: shortest window you can justify, ideally 48 hours.
Match the window to the reviewer's real pace. A procurement team that reads on Fridays needs more than 24 hours.
Make renewal painless
Short expiry fails when it creates friction. Put a note in the message: "This link expires on the 26th. Reply and I will refresh it." Keep a standing owner for these requests so a renewal takes minutes, not a thread of back and forth.
Also record the expiry date next to the document in your sharing register, so you know when a link has gone quiet and can follow up with the customer.
Pair expiry with other controls
Expiry is one layer. Combine it with named recipients, a download log where your tool offers one, and a file that carries its own as-of date and version. If a link is forwarded, the date on the page still tells the reader how old the content is. For the access side, see log who opened your shared security evidence.
Safeguard can generate the SBOM and compliance evidence you share, so you refresh a file instead of rebuilding it by hand. You can try a free scan to see what an export looks like.
Quick check
Is 7 days too short for a customer security review?
Usually not. Most reviews open the file within a few days. If they need more time, issuing a new link takes a minute and gives you a fresh touchpoint.
Should a never expiring link ever be used?
For security documents, rarely. If a document is meant to be public, publish it openly. If it is sensitive, give it an expiry or move it behind a login.
Sources
- Sharing objects with presigned URLs, Amazon S3 User Guide
- Manage sharing settings for SharePoint and OneDrive, Microsoft Learn
- Share files from Google Drive, Google Help
Last reviewed: 19 October 2026.
