For IT teams and MSPs

Password sharing for IT teams and MSPs who are tired of “I’ll text it to you”

You reset passwords, set up accounts, onboard clients and hand admin access back when a contract ends. Most of those handovers still go through email, Teams or a ticket comment, where they stay for years. ShareShield turns each one into a link that opens once and then deletes the password.

01What your tenant keeps

You know better than anyone how long an email lives

You run the mail system, so you know where a password in an email ends up. In Microsoft 365 alone, that’s:

  • the retention policies and Litigation Hold that keep the message after the user deletes it
  • the eDiscovery and content searches a compliance admin can run across every mailbox
  • the delegates and shared-mailbox members who can open it
  • every phone and laptop the user syncs, each with its own search index
  • your backups, and the client’s, kept for as long as your contract says

Teams chats are retained and searchable in the same way. Then multiply by the client’s tenant at the other end, and by anyone who ever compromises one of those accounts.

A one-time link leaves all of those holding a link that no longer opens anything.

02Your week, in credential handovers

Four tickets you closed last week

#10482Service requestP3Resolved

User locked out, needs temporary password

The usual wayReset it, then read it out on a call or paste it into the ticket reply, where it sits in the ticket history and the user’s inbox.

With ShareShieldPaste the temporary password, set one view and a four-hour expiry, add a passcode and read the passcode out on the call. Put the link in the ticket reply. When the user opens it, the password is deleted, and the ticket history holds a dead link.

#10495OnboardingP3Resolved

New client onboarding: need registrar and M365 admin access

The usual wayThe client’s office manager emails you the global admin password and the domain registrar login, copied to two colleagues for good measure.

With ShareShieldSend them a secret request for each credential. They fill in a one-time form, and the password lands in your ShareShield account instead of three inboxes. Recovery codes and certificate files can come back as files on Standard and above.

#10511IncidentP1Resolved

Engineer needs the shared break-glass account for a P1

The usual waySomeone pastes it into the incident channel, where everyone in the channel now has it.

With ShareShieldSend it to the engineer as a recipients-only secret. Only their verified address can open it, and the audit log shows who sent it, to whom, and when it was opened. Rotate it once the incident is closed, as you would anyway.

#10530OffboardingP4Resolved

Contract ending: hand admin accounts back to the client

The usual wayA spreadsheet of logins, emailed as an attachment, with “please change these” in the body.

With ShareShieldSend each account as its own secret, or the export as a file secret, emailed straight to the client’s named contact and locked to them. Ask them to change each password as they receive it. Your record of the handover is in the audit log, not in your sent folder.

Request a password

03Set it up once for the whole desk

Rules the whole desk follows without being reminded

Make ShareShield an organisation and the defaults stop depending on who is on shift.

Owners set a maximum and default expiry and view count, require a passcode on everything, stop files or requests, and limit which email domains a secret can be sent to (your own and your clients’, say). The send form locks to the policy, and so does the API.

See team controls

  • Roles that match the desk

    Technicians are members, team leads are admins, and whoever sets the policy is the owner (only owners can change it). Admins see every technician’s secrets and requests, never their contents, and can burn any of them: what you want when one goes to the wrong client.

  • Sign-in on your terms

    Require two-factor authentication for the whole organisation, or connect Microsoft Entra ID and enforce single sign-on for everyone on your verified domain.

04The question the auditor asks

Evidence for when the auditor asks how passwords are handed out

ISO/IEC 27001:2022 has a control for exactly this (Annex A 5.17, authentication information), and client security questionnaires ask the same thing in plainer words.

With ShareShield, the answer is a policy you can screenshot and a log you can filter: every secret created, emailed, opened, burned or locked out, with who did it and when. The log never contains the passwords themselves.

On Professional and Enterprise, export the log as CSV for the evidence pack.

Read the security model

05Which feature does what

What you’d use, job by job

ShareShield features for common IT and MSP jobs
JobFeature
Give a user a temporary passwordOne-view link with a short expiry and a passcode
Get a credential from a clientSecret request
Send recovery codes or a certificateFile secret (Standard and above)
Make sure only the named person opens itEmail recipients, recipients only
Stop technicians sending week-long linksEnforced policy: maximum expiry and views
Show how it was doneAudit log, CSV export on Professional and Enterprise
Create and send credentials from a scriptAPI v2 with a key scoped to secrets:create

06Further reading

Before you hand over the next one

Close the next password ticket with a link that deletes itself

Send a one-off secret without an account, or start an organisation and set the policy for the whole desk.