The Gap Between Access Control and Identity Verification

Password Pusher has always offered two ways to restrict access to a secret link: view limits and passphrases. Both serve their purpose, but neither answers a more fundamental question — is the person opening this link actually the person I sent it to?

A passphrase is a shared secret. Anyone who has it can use it. It has to be communicated through a separate channel, and it can be forwarded just as easily as the link itself. View limits cap how many times a link can be opened, but they don’t distinguish between the intended recipient and someone who happened to get the forwarded link first.

Authenticated Recipients addresses this directly. Instead of proving you have a code, you prove you are the intended recipient — by demonstrating control of the email address the sender authorized.

How It Works

When you create a push using Auto-Dispatch (which emails the secret link to recipients on your behalf), a new option appears: Require Email Verification.

With this enabled, anyone who opens the secret link sees an email challenge before the payload is revealed:

1. The recipient enters their email address.
2. If the email matches the authorized recipient list, a 6-digit one-time code is sent.
3. The recipient enters the code to unlock the secret.
4. The code is single-use and expires quickly.

If the email doesn’t match the allowlist, the same interface is shown — but no code is sent. This is deliberate: no information leaks about who was supposed to receive the secret, and there’s no way to enumerate the recipient list by probing.

What This Means for Compliance

For organizations that need to demonstrate controlled delivery of sensitive information, the audit trail now includes identity verification events alongside view events. The difference matters: previously, audit logs could show that someone viewed a secret at a given time from a given IP. Now they can show that the viewer proved their identity before accessing the content.

This is relevant for security questionnaires, internal compliance policies, and any workflow where “prove it was delivered to the right person” is a requirement — not just “prove it was delivered.”

Stacking With Existing Controls

Authenticated Recipients integrates with the features you already use:

• Auto-Dispatch. The recipient list comes from the same emails you’re already sending to. The verification checkbox is a single additional option on the push creation form.
• Passphrases. Both controls can be active simultaneously. The recipient verifies their email and enters a passphrase. The flow handles each step in sequence.
• Requests. This works for credential requests too — when someone submits a response to your request, they verify their identity first.
• Policies. Account admins can set the default behavior, enforce verification on all pushes, or leave it as a per-push decision for individual users.

Security Implementation

A few details on how the verification is built:

Where This Might Not Be the Right Fit

Authenticated Recipients requires Auto-Dispatch recipients — the feature activates when you specify email addresses for automatic delivery. If you’re sharing a link manually (copying it from the preview page and pasting it into a chat message or your own email), there’s no recipient list to verify against. In that case, passphrases remain the access control mechanism.

The verification also depends on email delivery. If your recipient’s email is delayed or filtered to spam, they’ll need to wait for the code to arrive. For time-sensitive scenarios where the recipient is standing next to you, a passphrase is faster.

Availability

Authenticated Recipients is available now on pwpush.com for Premium, Pro, and Enterprise plans. It will be included in the next Self-Hosted Pro release.

This has been one of our most requested features — the original community request dates back to early 2024. I’m glad it’s here.

Peter Giacomo Lombardo Founder & Principal, Apnotic · Creators of Password Pusher

This is a Feature Pipeline release: auto-dispatch has been available on pwpush.com as part of the Pro edition, and is now included in OSS Password Pusher for all self-hosted deployments.

The Copy-Paste Problem

Every secret-sharing tool works roughly the same way: you create a self-destructing link, copy it, and then paste it into an email or chat message to send it along.

That last step — the manual copy-paste — has always been a minor annoyance for individual users and a real bottleneck for teams and MSPs who share credentials dozens of times a day. It also means the delivery method is entirely outside the application, so there’s no audit trail of who the link was sent to, only who viewed it.

v2.9.0 closes that gap.

What Is Auto-Dispatch?

When you create a push, you can now enter one or more recipient email addresses directly in the form. OSS Password Pusher will email the secret link to each recipient on your behalf, with a clear message explaining what it is, how long it lasts, and what to expect.

A few things worth noting:

• Up to 5 recipients per push. You can send to multiple people at once, comma-separated.
• Language selection. Choose the language for the email and the secret link page. This is useful when your recipients speak a different language — Password Pusher supports over 30 locales.
• Available on all push types. Text pushes, file pushes, URL pushes and QR pushes all support auto-dispatch.
• Works from the preview page too. Forgot to add recipients when creating? You can send the email from the push preview page after creation.

What Does the Recipient See?

Recipients receive an email with the secret link, who sent it, how long the link is valid, and a note about passphrases if one was set. The email is clean and straightforward — no marketing, no branding distractions.

Full Audit Trail

Every auto-dispatch action is recorded in the push audit log. You can see:

• When the email was queued
• Who it was sent to
• The delivery status: pending, processing, completed, partially failed, or failed
• Any error messages if delivery didn’t succeed

This is important for compliance and accountability. Previously, if you shared a link via email manually, Password Pusher had no record of who you sent it to — only who eventually viewed it. Now, the full lifecycle is tracked: creation → email dispatch → each view → expiration.

How Does It Work Under the Hood?

Auto-dispatch activates automatically when SMTP is configured on your instance. If your instance can send email, the auto-dispatch fields appear in the push creation form for signed-in users.

When a push with recipients is created, the application enqueues a background job that delivers one email per recipient. The job has built-in retry logic for transient SMTP failures.

There’s a configurable daily limit per user (default: 500 emails/day) to prevent abuse, and you can disable the feature entirely if you don’t want it.

Configuration

Two new environment variables:

Or in settings.yml:

notify_by_email:
  enabled: true       # Set to false to fully disable
  daily_limit: 500    # Set to 0 to block sends, null for unlimited

For the full configuration reference, see the Notify by Email documentation.

API Support

The JSON API v2 supports auto-dispatch in two ways:

1. On push creation — include notify_emails_to and optional notify_emails_to_locale:

curl -X POST "https://your-instance.com/api/v2/pushes.json" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "push": {
      "payload": "my-secret-password",
      "expire_after_days": 3,
      "expire_after_views": 5,
      "notify_emails_to": "alice@example.com, bob@example.com",
      "notify_emails_to_locale": "fr"
    }
  }'

2. For existing pushes — send notifications after creation:

curl -X POST "https://your-instance.com/api/v2/pushes/YOUR_URL_TOKEN/notify_emails" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "notify_emails_to": "alice@example.com",
    "notify_emails_to_locale": "en"
  }'

The audit log endpoint also returns email dispatch events, so you can programmatically check delivery status.

For teams and MSPs who script their credential sharing workflows, this is a meaningful improvement: you can now create a push and deliver it to the recipient in a single API call.

Feature Pipeline

Auto-dispatch has been part of the Pro edition on pwpush.com for some time. With v2.9.0, it’s now included in OSS Password Pusher for all self-hosted deployments.

This is how the Feature Pipeline works: Pro subscribers on pwpush.com get early access to new features, and over time, those features move into the open-source codebase. Subscribers fund the development; OSS Password Pusher is the eventual beneficiary.

If you’re running a self-hosted instance, upgrade to v2.9.0 and make sure SMTP is configured — the feature activates automatically from there.

Where This Might Not Be the Right Fit

Auto-dispatch sends emails through your instance’s configured SMTP server. If your SMTP provider has strict sending limits (e.g., Gmail’s 500/day for personal accounts), the daily cap setting lets you stay within those limits. For high-volume use cases, a transactional email provider like SendGrid or Amazon SES is recommended.

Also, auto-dispatch requires signed-in users — anonymous pushes can’t trigger email notifications, by design. This prevents the feature from being used for spam.

Peter Giacomo Lombardo Founder & Principal, Apnotic · Creators of Password Pusher

The Problem Everyone Knows About

If you work in IT, run a web agency, manage infrastructure for clients, or handle onboarding for any kind of service — you’ve been in this situation. You need a password from someone. A client, a vendor, a new hire, a colleague in another department.

So you ask for it. And what happens next is almost always the same.

They email it to you. Or they paste it into a Slack message. Or a Teams chat. Or a shared Google Doc. Or — and this one still surprises me — a text message.

That password now lives in a system designed to keep messages forever. Searchable, forwardable, sitting in logs and backups long after anyone remembers it exists. Every compliance framework tells you not to do this. Everyone does it anyway, because there hasn’t been a simple alternative.

What “Securely” Actually Means Here

There are a few properties that matter when collecting credentials from someone:

• Encrypted in transit and at rest. The password should never be visible as plain text in a database, an inbox, or a log file.
• Self-destructing. Once you’ve retrieved the credential, the data should be permanently deleted. Not archived. Not soft-deleted. Gone.
• Audit-logged. You should know exactly when the credential was submitted and when it was retrieved — for your own records and for compliance.
• No account required for the sender. If collecting a password requires your client to sign up for a service, install an app, or figure out PGP, they’ll just email it to you instead.

That last point is the one most solutions get wrong.

The Old Way vs. the New Way

Password manager sharing is secure, but it only works when both parties use the same manager — which almost never happens across company boundaries. Request links solve the cross-organization problem.

How Requests Work in Password Pusher

Requests flip the direction of Password Pusher’s core mechanic. Instead of creating a secret and sending a link to a recipient, you create a request and send the link to the person who has the secret.

Here’s the flow:

1. You create a Request. Give it a name (e.g., “Staging server credentials”), set expiry rules, and optionally add your branding.
2. You send the Request link. Email it, message it, put it in a ticket — the link itself contains no sensitive data.
3. Your client opens the link and submits their credentials. The submission is encrypted before it’s stored. No account needed.
4. You get notified and retrieve the submission. Every access is logged. The data self-destructs after your configured limits.

The entire exchange is encrypted with AES-256, audit-logged from creation through retrieval, and permanently deleted once it expires.

Where This Fits in Practice

The most common use cases we see:

• MSPs and IT service providers collecting login credentials during client onboarding
• Web agencies gathering CMS, hosting, and DNS credentials from new clients
• Internal IT requesting WiFi passwords, VPN configs, or service account credentials from other departments
• HR and finance collecting sensitive employee information during onboarding
• Compliance teams receiving credentials for vendor assessments

If you’re already using Password Pusher to send passwords, Requests are the other half of the workflow.

What About Other Options?

A few purpose-built tools have appeared for credential collection — CredentialShare, SecureBin, and various WordPress plugins. They tend to focus narrowly on the intake form and skip the broader workflow: team management, custom domains, white-label branding, file attachments, API access, and self-hosted deployment.

Password Pusher Requests include all of those, and they work consistently whether you’re on the hosted service at pwpush.com or running a self-hosted instance on your own infrastructure.

Where Requests May Not Be the Right Fit

If you need ongoing, persistent access to a credential — like a shared service account password that multiple team members use daily — a password manager with a shared vault is the right tool. Requests are designed for one-time handoffs, not persistent storage.

If your organization requires SAML-based SSO for every tool in the stack, note that Password Pusher supports OIDC (OAuth2) on the self-hosted Enterprise tier. SAML is not currently supported on any tier.

Getting Started

You can create a Request right now with a free account. The recipient doesn’t need an account — they just open the link and submit.

For teams that need audit trails, branding, and custom domains, those are available on Pro plans. For organizations that need to keep everything on their own infrastructure, Self-Hosted Pro includes Requests with full API access.

The next time someone asks “just email me the password” — send them a Request link instead.

Peter Giacomo Lombardo Founder & Principal, Apnotic · Creators of Password Pusher

Those guides aren’t wrong. But they’re answering the wrong question.

The better question is: should sensitive information be in an email at all?

The Short Answer

No. Don’t put the password in the email. Put it behind a one-time link that self-destructs after it’s been read. Send that link through email — or Slack, or Teams, or text. The sensitive data never touches anyone’s inbox.

That’s it. That’s the whole approach. If you want to get started right now, go to pwpush.com, paste your secret, and you’ll have a link in about five seconds. No account required.

If you want to understand why this is better, keep reading.

What’s Wrong With Password Protected Email

Password-protecting an email sounds secure. The problem is what happens after the recipient opens it.

The credential persists. Once your recipient reads the email, that password now sits in their inbox — indefinitely. It’s in your Sent folder too. Both are backed up, synced across devices, and archived by your email provider. That one credential you sent at 3pm on a Tuesday now exists in a half-dozen places, none of which you control.

Gmail Confidential Mode isn’t encryption. Google’s own documentation acknowledges this. The recipient can’t forward the email, but they can screenshot it. Google can still scan the contents. And the “expiration” just removes access to the email — it doesn’t delete the data from Google’s servers.

The password-for-the-password problem. If you encrypt an email, you need to get the decryption password to the recipient somehow. Most people send it in a separate email. So now you have two emails, both in inboxes, both persistent — and anyone who compromises the inbox gets both.

Forwarding and screenshots. Even with access controls, you can’t prevent someone from copying the text and pasting it somewhere else. The fundamental issue isn’t access control — it’s that email is a persistent medium, and credentials shouldn’t persist.

The One-Time Link Approach

Instead of trying to make email secure, take the sensitive data out of email entirely.

1. Put the credential behind a one-time link
2. Send the link through whatever channel you’d normally use — email, Slack, Teams, text
3. The recipient clicks the link and sees the credential
4. The link self-destructs. The data is deleted.

The email still exists in both inboxes, sure. But it contains a link to something that no longer exists. Anyone who finds that email later — whether through a breach, a forwarded thread, or an old backup — gets nothing.

How Password Pusher Works

Password Pusher is built specifically for this:

• Paste your secret at pwpush.com and set a view limit and expiration
• Get a one-time link — send it however you want
• Recipient clicks the link and sees the secret
• The data self-destructs after the view limit or time limit is reached

No account required. No software to install — for you or the recipient.

A few extras that matter: a retrieval step that prevents URL preview bots (Slack, Teams, iMessage) from consuming views before your recipient sees them. Passphrase protection for an extra layer. An audit trail showing when links were accessed. And auto-dispatch to email the link directly to the recipient on your behalf.

Password Pusher has been in production since 2011 — over fourteen years. The security-critical code is fully open source and auditable on GitHub. Over 100 million secrets shared. You can use it for free, or get Pro features like team collaboration, custom domains, and white-label branding for your organization.

Quick Recap

The safest email is the one that doesn’t contain the secret.

Peter Giacomo Lombardo Founder & Principal, Apnotic · Creators of Password Pusher

Most of the time, that’s not what you need. You need to get a file to someone securely, know when they’ve accessed it, and have the whole thing disappear when it’s done.

The Quick Answer

Password Pusher lets you attach files to a self-destructing link. Upload the file, set an expiration, share the link. The recipient clicks it, downloads the file, and the link expires after the view limit or time limit you set. No account required — for you or the recipient.

If that’s enough to get started, go to pwpush.com and try it. No signup needed.

If you want to understand the full feature set, keep reading.

How File Sharing Works in Password Pusher

The workflow is the same whether you’re sharing a text password or a file — or both at the same time.

1. Go to pwpush.com and create a new push
2. Attach one or more files alongside any text or notes you want to include
3. Set your expiration — how many views and how many days before the data is deleted
4. Get your link — a unique, one-time URL you can send through email, Slack, Teams, or any other channel
5. Share it — your recipient clicks the link and downloads the files

After the view limit or time limit is reached, the files and any associated text are deleted. Not archived somewhere. Deleted. The link goes dead, and anyone who finds it later gets nothing.

You can also add a passphrase so the recipient needs both the link and a separate password to access the files — useful when you’re sending something particularly sensitive.

Track Who Accessed Your Files

This is where Password Pusher goes beyond basic file sharing. Every push comes with a complete audit trail:

• Who opened the link — IP address and geographic location
• When they accessed it — exact timestamp
• How many times the link has been viewed
• Whether it’s still active or has expired

You can also turn on access notifications so you get alerted the moment someone opens your link. For compliance-sensitive workflows — legal, finance, healthcare, IT — knowing exactly when and where a file was accessed isn’t optional. It’s required.

And if you need to revoke access before the expiration? One click. The link dies immediately.

Why Not Just Use Dropbox or Google Drive?

Those platforms are great for ongoing collaboration. But they’re designed for files that stick around — shared folders, persistent access, version histories. That’s the opposite of what you want when sharing sensitive documents with a client or contractor.

When you share a file through a cloud drive:

• The file persists in shared folders, recent files, and backups — indefinitely
• Access is ongoing unless you remember to revoke it
• Recipients need accounts on the same platform
• No audit trail for individual file access at the link level

Password Pusher is built for the other use case: ad-hoc, temporary file delivery where the file should stop existing after it’s been received.

Send a contract draft to a client. Deliver API credentials with supporting documentation. Share tax documents with your accountant. Get configuration files to a contractor. In all of these cases, the file needs to get there, the recipient needs to confirm receipt, and then the file should be gone.

Built for Teams and Organizations

If you’re sharing files across a team, Password Pusher Pro adds the features organizations need:

• Custom domains — share links from your own domain instead of pwpush.com
• White-label branding — your logo, your colors, your messaging. Recipients see your brand, not ours
• Team dashboards — shared visibility into all pushes across your organization
• Workspace policies — enforce expiration limits, passphrase requirements, and other security rules organization-wide
• API and CLI — automate file distribution through your existing workflows

Pro is available as a hosted service on pwpush.com — with dedicated EU and US data regions — or as a self-hosted license for organizations that want files on their own infrastructure.

Getting Started

Text and password sharing on pwpush.com is free — no account required. File sharing is available with Premium and Pro subscriptions, starting at $19/month.

If you’d rather self-host, the open source edition includes file sharing out of the box. Deploy it on your own infrastructure and start sharing files immediately.

The platform has been in production for over fourteen years — AES-256 encryption, more than 100 million secrets shared, and a fully auditable open source codebase. No portal. No enterprise contract.

Peter Giacomo Lombardo Founder & Principal, Apnotic · Creators of Password Pusher

And almost everybody does it the same way: paste it into an email, drop it in Slack, or text it.

It works. Until it doesn’t.

The Problem With How We Share Passwords

When you send a password through email or a messaging app, that credential now lives in multiple places indefinitely — your sent folder, their inbox, the messaging server’s database, backups, email archives, possibly synced to multiple devices. That one password has gone from existing in one place to potentially dozens.

This isn’t a theoretical risk. Credential exposure through persistent messages is one of the top vectors in data breaches. An old Slack DM from 2023 containing a database password is just as dangerous in 2026 if that password hasn’t been rotated — and let’s be honest, it probably hasn’t been.

The best way to securely share passwords is to make sure they don’t persist after they’ve been received.

One-Time Links: The Simple Answer

The concept is straightforward: instead of sending the password directly, you generate a link that contains the password. The recipient clicks the link, sees the password, and the link self-destructs. Gone. No copies lingering in inboxes or message histories.

This is the best way to send passwords whether you’re sharing them with colleagues, clients, or anyone else — because the credential simply stops existing after it’s been read.

What makes this better than the alternatives:

• No persistence. The password doesn’t live in email archives, chat logs, or backup tapes.
• No account required. The recipient doesn’t need to install anything or create an account. They click a link.
• Audit trail. You can see when the link was opened, how many times, and whether it expired unused.
• Works everywhere. Send the link through whatever channel you already use — email, Slack, Teams, text. The channel is just the delivery mechanism. The credential itself is behind the one-time link.

This last point matters a lot when you’re sharing passwords with clients. Your client doesn’t want to install your company’s password manager. They don’t want to create an account on a tool they’ll use once. They want to click a link and get the credential. Done.

How Password Pusher Works

Password Pusher is built specifically for this. Here’s the workflow:

1. Go to pwpush.com
2. Paste your password or secret
3. Set how many views and how many days before it expires
4. Click “Push it!” — you get a unique link
5. Send that link to your recipient

That’s it. When they open the link, they see the password. After the view limit or time limit is reached, the data is deleted. Not archived. Deleted.

A few things that matter in practice:

Retrieval step. When you send a link via Slack, Teams, or iMessage, URL preview bots will automatically fetch the link before the recipient even sees it. If the tool counts that fetch as a “view,” the secret might already be gone. Password Pusher includes a one-click retrieval step that stops bots from burning your links.

Passphrase protection. For particularly sensitive credentials, you can add a passphrase. The recipient needs both the link and the passphrase to see the content — a clean two-factor delivery.

Auto-dispatch. If you’d rather not deal with sending the link yourself, Password Pusher can email it directly to the recipient on your behalf.

Why 345,000+ People Use It Every Month

Password Pusher has been in production since 2011. Over fourteen years. That’s a long time for a security tool — and longevity matters when you’re trusting something with credentials.

The core application is fully open source on GitHub. Every line of the security-critical code — the encryption (AES-GCM 256-bit), the data handling, the expiry logic, the audit logging — is auditable by anyone. Over 100 million secrets have been shared through the platform.

You can use it for free at pwpush.com with no account required. Or you can self-host it on your own infrastructure if you prefer to keep everything in-house.

Apnotic and Pro Subscriptions

In 2024, I founded Apnotic, LLC to put a proper company behind Password Pusher. The project had grown well beyond a side project, and it needed the support structure to match.

Password Pusher Pro is the subscription tier for teams and organizations. It adds team collaboration, custom domains, white-label branding, file sharing, and workspace-level policies — the features that matter when you’re using Password Pusher across a team rather than individually.

Pro is available both as a hosted service on pwpush.com — with dedicated EU and US data regions — and as a self-hosted license for organizations that need credentials on their own infrastructure.

The free tier isn’t going anywhere. It’s the foundation of the project and always will be. Pro is for the organizations that need more.

Peter Giacomo Lombardo — Apnotic, LLC

It’s the simplest way to share a password without leaving it sitting in an inbox, a chat log, or a shared document forever.

How One-Time Password Links Work

The concept has three parts:

1. You create the link. Paste your password into a tool that generates a unique URL. You set how many times the link can be viewed and how long it should stay active.
2. You send the link. Through email, Slack, Teams, text — whatever channel you’d normally use. The password isn’t in the message. Just the link.
3. The link self-destructs. After the recipient views it — or after the time limit expires — the data behind the link is deleted. The URL goes dead permanently.

The key difference from sending a password directly: the credential doesn’t persist. An email with a password in it is searchable, forwardable, and backed up indefinitely. An email with a one-time link in it becomes worthless the moment the link expires.

Why Use a One-Time Link Instead of Sending the Password Directly

Every time you paste a credential into an email or chat message, that credential now exists in multiple places you don’t control — sent folders, recipient inboxes, message server databases, cloud backups, synced devices. One credential, potentially dozens of copies.

A one-time password link changes the equation:

• The password lives in one place — behind the link — until it’s viewed or expires
• You control the lifecycle — set view limits (1 view, 5 views, whatever you need) and a time window (hours, days, or weeks)
• You get an audit trail — know when the link was opened, from where, and how many times
• The recipient doesn’t need an account — they click a link, that’s it
• You can revoke it early — if you sent the link to the wrong person, kill it before they open it

This works equally well for sharing credentials with colleagues, sending temporary passwords to clients, or distributing API keys to contractors. The recipient gets what they need. The credential doesn’t outlive its purpose.

How to Create a One-Time Password Link

Password Pusher has been doing this since 2011. Here’s the workflow:

1. Go to pwpush.com — no account required
2. Paste your password, API key, or any text you need to share
3. Set your view limit (how many times the link can be opened) and expiration (how many days or hours before it’s deleted regardless)
4. Optionally add a passphrase — the recipient will need both the link and the passphrase to see the content
5. Click “Push it!” and copy the generated link
6. Send the link to your recipient however you want

When they open the link, they see the credential. After the view limit or time limit is reached, the data is permanently deleted.

What About URL Preview Bots?

This is a real problem that most one-time sharing tools ignore. When you send a link through Slack, Microsoft Teams, or iMessage, those platforms automatically fetch the URL to generate a preview. If the tool counts that fetch as a “view,” the password might be consumed before the recipient ever sees it.

Password Pusher handles this with a one-click retrieval step. When someone opens a push link, they see a landing page first — they have to click a button to reveal the content. Bots don’t click buttons. The recipient does.

Temporary Passwords and Short-Lived Credentials

One-time password links are especially useful for temporary passwords — credentials that only need to exist long enough to get someone logged in.

Common use cases:

• New employee onboarding — send initial login credentials that expire after first use
• Client handoffs — share staging server access or admin passwords for a project deliverable
• IT support — distribute temporary passwords for password resets
• Vendor access — give a contractor credentials for a specific system, knowing the link dies after they’ve used it

Set the view limit to 1 and the expiration to 24 hours, and you’ve created a credential that quite literally cannot persist beyond its intended purpose.

Beyond Text — Files, URLs, and More

Password Pusher isn’t limited to text passwords. You can attach files alongside your push — share a credential document, a configuration file, or an SSH key, all behind the same self-destructing link. You can also push URLs and QR codes with the same expiration controls.

File sharing requires a Premium or Pro subscription on the hosted service. If you self-host the open source edition, file sharing is included out of the box.

Open Source and Fourteen Years in Production

Password Pusher has been running since 2011. The security-critical code — AES-256 encryption, data handling, expiry logic, audit logging — is fully open source and auditable on GitHub. Over 100 million secrets shared to date.

The free tier on pwpush.com handles one-time password links with no account required. Pro subscriptions add team collaboration, custom domains, white-label branding, and workspace policies for organizations. Available hosted — with dedicated EU and US data regions — or self-hosted on your own infrastructure.

Peter Giacomo Lombardo Founder & Principal, Apnotic · Creators of Password Pusher

For a while now, we’ve been noticing something in our traffic data: a lot of managed service providers already use Password Pusher.

Referral traffic from ConnectWise, Kaseya, IT Glue, Atlassian — MSP tools are consistently some of our top traffic sources. It makes sense. If you’re an MSP handing off WiFi passwords, admin credentials, or license keys to clients every day, you need a way to do that without leaving those credentials sitting permanently in a ticket history or email thread.

What we hadn’t done is acknowledge that directly on the site. Until now.

What’s New

We’ve launched a dedicated MSP page that speaks directly to how managed service providers use Password Pusher — the workflow, the compliance angle, and the specific features that matter most for credential delivery at scale.

We’ve also built out a Partner Program for MSPs and IT services companies who want to resell Password Pusher Pro self-hosted licenses to their clients.

The Partner Program

The mechanics are straightforward:

• Volume discounts from 30% to 50% off self-hosted Pro licenses, based on your lifetime license count. Your discount tier never goes down.
• Free NFR license — one free Advanced-tier license for your own internal use, granted automatically when you’re accepted as a partner.
• Automatic discount application — no special codes or manual processes. Your discount is applied at checkout based on your tier.

The idea is simple: use Password Pusher internally, know it works, and offer it to your clients with margins that make sense for your business.

Why This Matters for MSPs

The credential sharing problem in the MSP world is well understood. Passwords end up in PSA ticket notes, email threads, Slack messages — places where they persist indefinitely and are searchable by anyone with access.

Beyond the obvious security risk, there’s a growing compliance angle. Cyber insurance underwriters are increasingly asking MSPs about per-client credential isolation and documented delivery processes. Having an audit trail that shows a credential was delivered via an expiring link, viewed once, and automatically destroyed is exactly the kind of evidence that satisfies those questions.

Password Pusher handles this with self-destructing links, full lifecycle audit logging, optional passphrase protection, and one-click retrieval to prevent URL scanners from consuming views. For MSPs doing volume, Auto-Dispatch emails the secure link directly to the client — no copy-paste required.

And for MSPs with strict compliance requirements, the self-hosted option puts everything inside your own infrastructure. Your SOC 2, your controls, your data.

Getting Started

If you’re an MSP already using Password Pusher, the Partner Program is worth a look — especially if you’re deploying self-hosted instances for clients.

If you’re new to Password Pusher, the free tier on pwpush.com is the fastest way to try it. No credit card, no signup required for basic pushes.

Either way, the new MSP page has the full picture of how it all fits together for managed service providers.

Peter Giacomo Lombardo — Apnotic, LLC

The communication around it wasn’t great either. Fast Company covered the backlash, specifically calling out the “$1.65/month billed annually” framing when there’s no monthly billing option. That’s the kind of pricing trick that erodes trust, especially from a company that built its reputation on transparency.

Since then, I’ve watched a steady stream of people looking for Bitwarden Send alternatives. Which makes sense — if you were using Bitwarden primarily for Send (their secure sharing feature), a 98% price increase on what was already a secondary feature is a reasonable reason to look around.

I built Password Pusher, so I’m obviously not a neutral party here. But I’ve been building secure sharing tools since 2011 and I think I can offer some useful perspective on what to actually evaluate — regardless of where you end up.

The Price Hike Isn’t Really the Problem

Look, $20/year is still cheap software. If Bitwarden Send did everything you needed, the price increase alone probably wouldn’t be worth switching over.

The real question the price hike forces is: should you be paying for an entire password manager just to share secrets?

Bitwarden is a solid password manager. But Send is a feature inside that password manager — not a standalone product. Its roadmap, its priorities, its development resources are all driven by the password management use case. Sharing is secondary.

That’s not a knock on Bitwarden. It’s just the reality of how product development works. When you need a screwdriver, buying a whole toolbox works — but you’re paying for a lot of tools you don’t need.

And the price hike is part of a broader pattern that has the community paying attention. New CEO with private equity experience. “Always free” quietly removed from the website. Company values like “Transparency” and “Inclusion” scrubbed. People in the Bitwarden subreddit are drawing direct comparisons to the LastPass trajectory, and I can’t say those concerns are unfounded.

What Actually Matters in a Secure Sharing Tool

If you’re evaluating alternatives, here’s what I’d focus on:

Does it require an account to send? Most people sharing a secret need to do it right now. If the tool requires signup and login before you can share anything, that’s friction at exactly the wrong moment. Bitwarden Send requires a Bitwarden account. Some alternatives don’t.

What’s the expiry model? You want granular control over both view limits and time limits. Bitwarden Send caps at 31 days maximum. Some tools go longer. For most use cases, the more control you have over the lifecycle of a shared secret, the better.

Is there an audit trail? If you’re sharing credentials in a business context, you need to know: was this link opened? When? How many times? Bitwarden restricts audit logging to their Teams and Enterprise plans. For a tool focused on secure distribution, per-item audit logging should be the baseline — not a premium upsell.

Can it be self-hosted? If you’re in a regulated industry or just prefer to keep secrets on your own infrastructure, self-hosting matters. Both Bitwarden and some alternatives offer this — but the depth of self-hosted features varies widely.

Does it handle URL preview bots? This one gets overlooked. When you send a link via Slack, Teams, or iMessage, URL preview bots fetch that link before the recipient ever sees it. If the tool counts that bot fetch as a “view,” your recipient might find the secret already expired. A good sharing tool has a retrieval step or other mechanism to prevent this.

Where Password Pusher Fits

Password Pusher is purpose-built for exactly this use case — secure, temporary sharing of sensitive information. It’s been in production since 2011, it’s fully open source, and it’s handled over 100 million secrets to date.

No account required to send. Per-push audit logging on every tier. View limits, time limits, passphrase protection, and a one-click retrieval step that prevents bots from burning your links. Self-hosted or SaaS with dedicated EU and US data regions.

I wrote a detailed comparison page that puts Password Pusher and Bitwarden Send side by side — feature for feature — including the areas where Bitwarden is genuinely stronger (like their end-to-end encryption model). I’d encourage you to take a look:

Password Pusher vs. Bitwarden Send — Full Comparison →

One More Thing

Price hikes have a way of forcing useful conversations. If the Bitwarden increase made you actually evaluate what you need from a sharing tool, that’s a good outcome regardless of what you choose.

My hope is that this post helps a few people make a more informed decision. There are several solid options out there. Password Pusher is one of them, and it’s the one I’ve spent the last 14+ years building to be the best at this specific job.

Peter Giacomo Lombardo Founder & Principal, Apnotic · Creators of Password Pusher

A text input. Some encryption. A submit button. That was it. I pushed it to production, open-sourced the code, and went back to my day job. I didn’t think about it much after that.

But someone used it. And then someone else did. And then a few more.

“Go Ahead. Email Another Password.” That was the tagline. That was the whole pitch. The product was barely a product — it was a reaction to a problem that annoyed me. People were emailing passwords in plain text. So I built the smallest thing that could fix that.

Then a strange thing started happening.

See that flat line from 2012 to 2014? That’s three years of almost nothing. Then a slow curve upward. Not fast. Not in any way that would make a headline. Just — every month, a little more. More Docker pulls. More people I’d never heard of, at companies I’d never heard of, quietly using this thing I built on a weekend.

Year after year. I’d add a feature. Fix a bug. Add another feature. The backlog grew. Feature requests started waiting six months. Then a year. Then longer.

And at some point — I don’t remember the exact moment — but sometime in late 2023-2024 I had to make a decision.

Option one: keep the pace. Hobby project. A few features a year. Nothing wrong with that.

Option two: find a way to make this thing self-sufficient. Work on it properly. But on my terms.

I went with option two.

Now here’s the part where most founders say they raised a round. Pitched VCs. Built a deck. Got a term sheet.

I didn’t do any of that.

Instead, I built a feature pipeline. Premium features for subscribers, with those features rolling into the open-source version over time. Customers fund development. Development benefits everyone. No investors, no debt, no one to answer to except the people using the product.

That became Apnotic.

And today — fourteen years after that weekend — we have 345K monthly active users. 50M+ Docker downloads. Over 100 million secrets shared. 400 paying customers. Healthy recurring revenue. A team of two, an advisor, and fourteen years of work that I genuinely enjoy showing up to every day.

All from a text input. Some encryption. And a submit button.