Skip to content
SafeHanded Docs

Quickstart: your first request

This walks you through SafeHanded end to end by requesting a credential from yourself, so you can see every stage before you use it for real. It takes about ten minutes. Setting up your key and sending your first request are also on the Getting started checklist in the app, which ticks itself off as you go.

Watch it first

Section titled “Watch it first”

Two 3-minute videos show the whole thing set up and in use:

Before you start

Section titled “Before you start”

You need an organisation and a browser with a passkey method available — Windows Hello, Touch ID / Face ID, a phone passkey, or a hardware security key. See passkey compatibility if you’re unsure.

There’s no separate sign-up form: sign in at safehanded.com/app with your work email (or work account) and your first sign-in creates your free organisation. Temporary or throwaway email addresses are refused.

1. Set up your secure key

Section titled “1. Set up your secure key”

On first sign-in, SafeHanded generates your identity key in your browser — the key credentials are encrypted to.

If you sign in by email, the emailed link opens a Continue signing in page. The link is used only when you press the button, so an email security scanner that opens it first doesn’t use it up.

  1. Create a passkey when prompted.
  2. Save your recovery phrase (24 words). It’s shown once. Store it somewhere safe — it’s how you unlock your key on a new browser, and the only way back in if you lose your passkey.
  3. If your passkey supports PRF, set it up as a one-touch way to unlock your key too.

That’s your key set up. Full detail: Passkeys & unlocking.

2. Send a request to yourself

Section titled “2. Send a request to yourself”
  1. Click New request.
  2. Template: choose a simple one, e.g. Windows password.
  3. Subject’s name: type your own name. The email and mobile are optional.
  4. Ticket reference: type something for now, e.g. TEST-1 (it’s optional), then Continue.
  5. Justification: enter at least ten characters (it’s required, and audited).
  6. Destroy the secret after: leave the default.
  7. Who else can reveal it?: leave it empty — you can always reveal your own request.
  8. How should they prove it’s them?: choose A spoken code so you can see it, then Continue.
  9. How does the link reach them?: choose I’ll share it myself, then Issue secure link.

You now have a handoff link to copy and a 6-digit spoken code.

3. Submit as the user

Section titled “3. Submit as the user”
  1. Open the copied link in another tab (or on your phone) — this is exactly what your user sees.
  2. Notice the branding, your name as requester, the ticket reference and the expiry.
  3. Enter the spoken code.
  4. Tick the confirmation, type a throwaway password, and click Encrypt and send.

The value is encrypted in that browser before it’s sent. The server only ever receives ciphertext.

4. Reveal it

Section titled “4. Reveal it”
  1. Back in the app, open the request — its status is now Submitted.
  2. Click Reveal and confirm with your passkey.
  3. The credential is decrypted in your browser. Hold to peek or copy it; it clears itself after a few seconds.

5. Complete and destroy

Section titled “5. Complete and destroy”

Click Complete and destroy. The encrypted record is deleted, the status becomes Completed, and the event is written to the audit log. If this had been a real ticket, closing the ticket would have done the same thing automatically.

What to set up next

Section titled “What to set up next”

You’ve seen the whole flow. Before real use, an admin should: