One-Time Secrets Just Got Smarter: Multi-Use Links, IP Restrictions, and 30-Day TTLs

Why We Built This

One-time secrets solve a real problem: sharing credentials without leaving them in Slack, email, or a spreadsheet forever. We’ve written about why this matters and how to use them.

But the “one view, one link” model doesn’t cover every scenario. Teams told us they needed:

• A way to share a credential with multiple people without creating separate links for each
• Longer expiration windows for secrets that need to live through a sprint or onboarding cycle
• Access restrictions so a secret can only be viewed from specific networks or regions
• A heads up before a secret expires so it doesn’t silently disappear

So we built all four.

1. Multi-Use Secrets: Configurable View Limits

The original one-time secrets model is simple: create a link, someone views it, it’s gone. That works when you’re sharing a password with one person. It doesn’t work when you need to share a staging database URL with a team of five.

You can now set a view limit between 1 and 100 when creating a secret. The secret stays active until it hits the view limit or the TTL expires, whichever comes first.

The viewer shows how many views remain, so recipients know how many times the link can still be used.

Use cases:

• Share a staging API key with a team of contractors, set a view limit of 10
• Distribute a shared service password to a new cohort of developers during onboarding
• Create a link your CI/CD pipeline can pull from multiple times during a deployment window

The default is still 1 view (true one-time), so nothing changes for existing workflows.

2. Longer TTLs: 7, 14, and 30-Day Expiration

Previously, secrets maxed out at shorter expiration windows. Now you can set TTLs up to 30 days, which covers real-world scenarios like:

• Onboarding cycles, a new hire starting next Monday needs credentials waiting for them
• Sprint-length sharing, share a key that stays available for the duration of a two-week sprint
• Cross-timezone handoffs, give international teams enough time to grab a credential without racing against a clock

3. IP and Country Restrictions

This is the feature security teams have been asking for. You can now restrict who can view a secret based on:

• IP addresses or CIDR ranges, allowlist specific IPs (e.g., 203.0.113.0/24) so the secret is only viewable from your office or VPN
• Country codes, restrict access to specific countries using ISO codes (e.g., US, GB, DE)

If someone outside the allowlist tries to view the secret, they get a 403, the secret content is never revealed.

Why this matters:

A one-time secret link is only as secure as the channel you send it through. If the link gets forwarded, screenshot’d, or intercepted, the wrong person can view it. IP and country restrictions add a second gate: even with the link, the viewer must be on an approved network or in an approved region.

Practical examples:

• Lock a production database password to your VPN’s IP range
• Restrict access to US-only for compliance with data residency requirements
• Allowlist your contractor’s static IP so only their office can access the credential

4. Expiration Notifications

Secrets expire silently. If you shared a credential with a 7-day TTL and the recipient forgot to open it, you wouldn’t know until they asked for it again.

Now you can opt into email notifications before a secret expires. Choose to be notified 1 hour, 6 hours, or 24 hours before expiration. The notification options are filtered based on your chosen TTL, a 1-hour secret won’t offer a 24-hour notification.

This is useful for:

• High-value credentials where you need to confirm delivery
• Onboarding flows where you want to know if a new hire hasn’t retrieved their credentials yet
• Compliance scenarios where you need to document that a credential was (or wasn’t) accessed before expiry

How It Works Together

These features compose naturally. Here’s a real scenario:

You’re onboarding three contractors who start next week. They’re all remote, working from a known office IP range in Germany.

1. Create a secret with the staging database URL
2. Set view limit to 5 (three contractors plus a buffer)
3. Set TTL to 14 days (covers the full onboarding window)
4. Add IP restriction for their office CIDR range
5. Add country restriction for DE
6. Enable 24-hour expiration notification

You share one link. Only people on the right network in the right country can view it, and you get an email if it’s about to expire before everyone has accessed it.

Security Model

The core security model hasn’t changed:

• All secrets are encrypted at rest with AES-256-GCM
• Zero-knowledge encryption means we never see your plaintext secrets
• Optional passphrase protection adds client-side encryption on top
• Audit trails track every view with timestamps (and now view counts)

The new features add restrictions on top of this foundation. IP and country checks happen server-side before the encrypted payload is ever returned to the client. Multi-use secrets still self-destruct, they just do it after N views instead of 1.

For more on the security architecture, see Zero-Knowledge Encryption for Enterprise Secrets Management.

Getting Started

All four features are available now in the secrets sharing tool. No signup required for basic usage; just create a secret and configure the options.

For teams that need 30-day TTLs and want to combine these features with authenticated secrets and audit trails, check out the full-tier plan.

Related Reading

• How to Share One-Time Secrets: Step-by-Step Guide
• Stop Sending Passwords in Slack: Secure Secret Sharing
• Authenticated Secrets: Building Comprehensive Audit Trails
• Zero-Knowledge Encryption for Enterprise Secrets Management