Skip to main content
Inkrypt logo

Product

Use cases

The same feature set gets used quite differently by a developer handing over an API key and an HR team sending offer details. These pages cover the patterns that hold up in each context — and the ones that look careful but are not.

Every scenario here is a version of the same underlying problem: a secret has to move from one person to another, and the obvious channel keeps a permanent copy. Email, chat and ticket systems are all designed to remember everything — usually a virtue, and precisely wrong for a credential.

What differs by context is the risk profile and the constraints. A developer can often avoid sharing entirely by provisioning a scoped account. An HR team sending offer details to a candidate with no company identity yet has no such option. The recommendations differ accordingly.

Developers

Hand over API keys, connection strings and tokens without leaving them in chat history or a ticket.

Read more

IT & DevOps

Onboarding, offboarding and emergency handoffs, without leaving credentials in a ticket forever.

Read more

HR & recruiting

Send offer details and personal data without leaving a permanent copy in an inbox.

Read more

Agencies & freelancers

Exchange client credentials across organisations that share no tooling — and stop accumulating them.

Read more

Personal use

Everyday private text — shared logins, travel details, drafts you would rather not leave in a chat app.

Read more

The pattern that applies everywhere

Across every context on this page, the same five steps do most of the work. If you take nothing else from these pages, take these.

  1. Avoid sharing if you can. A scoped individual account beats any secure transfer, because nothing moves at all.
  2. Split the channels. Link one way, password another. Both in the same message defeats the entire exercise.
  3. Set a short expiry. The default outcome should be deletion; keeping something around should be the deliberate choice.
  4. Confirm out of band. A two-word reply tells you the right person received it — and a view limit already consumed tells you someone else did.
  5. Rotate afterwards. Secure transport reduces exposure. It does not undo the fact that the secret moved.

Frequently asked questions

What is the most common reason people use encrypted notes?

Handing a credential to another person once. Almost every scenario on these pages is a variation of it — the alternative is pasting the secret into email or chat, where it stays permanently.

Is this suitable for regulated or sensitive personal data?

Client-side encryption and expiry reduce exposure, but Inkrypt has no accounts and therefore no attributable access logs. Controls requiring per-user audit trails cannot be satisfied by it. Check your own obligations before adopting it for regulated data.

Can a whole team use Inkrypt together?

There are no team accounts, shared vaults or permissions — those require identity, which Inkrypt deliberately does not have. Teams typically use a password manager for shared storage and Inkrypt for the handoff moment in between.

Does it work if the recipient has never used Inkrypt?

Yes, and this is often the deciding factor. The recipient needs a browser and the password. Nothing to install, no account to create — which is why it works across organisational boundaries where shared tooling does not exist.

Write your first encrypted note

No account, no email address, no download. Type a note, set a password, and share the link.

Open the notepad