Setting your policy
Policy sets the rules every request in your organisation must follow. Defaults are sensible — open Settings → Policy once and save to confirm them. For: Admins and Owners.
Saving the policy doesn’t ask for your passkey. Nor do the organisation mode, making people on your domains join you or a client’s branding. Every change is recorded in the audit log.
A few protected actions do ask you to confirm with your passkey:
- adding, removing, turning off or on a sign-in connection, or changing what it trusts (its tenant, certificates, metadata or client details)
- issuing or revoking a SCIM token
- changing someone’s role, inviting an Owner or Admin, or changing group roles
One confirmation covers them for 2 hours, and each protected action restarts the 2 hours. Signing out or switching organisation ends it. Reveals and passkey or recovery changes still ask every time.
Link lifetimes
Section titled “Link lifetimes”- Allowed TTLs — the expiry options technicians can choose from, and the default, from 5 minutes to 30 days.
- Link open window — how long an unopened link stays valid before it expires. Choose 15 minutes, 30 minutes, 1 hour, 4 hours, 8 hours or 1 day.
Shorter is safer; long enough that a user who’s away can still act in time.
Default preset
Section titled “Default preset”- Default preset for new requests — the preset a new request
starts from when none is named: from the New request button, a ticket link without
&preset=, the API or a ticket automation. A client’s own default preset wins for that client. Only organisation-wide presets are listed; with None, the defaults on this page apply.
Link lifetimes and the default preset are both under Requests & reveal on the Policy page.
Verification requirement
Section titled “Verification requirement”Under Subject verification, set the verification a new request starts with (Default for new requests) and the least a technician may choose (Minimum technicians may choose). Each is one of No verification, Spoken challenge code, Emailed one-time code, Either code or Both codes. The default must meet the minimum.
Requiring verification org-wide means a leaked link is never enough on its own.
Strict mode
Section titled “Strict mode”Turn on strict mode to stop identity keys being cached on devices — every reveal then unlocks via a passkey PRF. Confirm your team has PRF-capable passkeys first.
Purge trigger
Section titled “Purge trigger”Choose what closing a ticket does:
- Trigger status — purge on closed, or on resolved or closed (the default).
- Unsubmitted requests — revoke on close (default on).
- Grace period — 0–60 minutes, so a quick reopen can cancel the purge.
See Completing & purging.
Handover assurance
Section titled “Handover assurance”Active subject verification asks the subject to confirm who they are before the form unlocks: Call-back code (the subject reads a code to IT, who types it in) or Verified contact channel (the subject confirms out-of-band and IT confirms in the request). It’s off by default, and a client can override it on its branding page. Recommend rotation on completion flags a handed-over credential for rotation when a request completes.
Require single sign-on
Section titled “Require single sign-on”On the Team plan and above, with a sign-in provider connected, turn on Require single sign-on under Access & sessions so members must sign in through your identity provider. Email and passkey sign-in then works for Owners only, so you are never locked out. Members who ask for an email link are sent to your provider instead.
Share key locker
Section titled “Share key locker”Keep the key for the sender (key locker) (on by default) lets a technician give a share’s key later from the share page: the key words, the whole link, or a 6-digit code on a call (see Send a secret). The key is locked to the technician’s own key, so SafeHanded cannot read it, and it is deleted when the share is first viewed or ends. Turning it off deletes every key already kept; technicians then give the key when they create the share.