There's an open secret in every IT department. The new hire starts Monday. You set up their directory account. You set their password, and then you... Slack it to their manager? Email it in plaintext? Write it on a sticky note?
Yup. That's what most companies do. And honestly, I get it; I used to do that as well. What else are you supposed to do? The person doesn't have a work email yet, we’re generating that, so it doesn’t exists! They can't log into SSO, cause they don’t have creds. They might not start for two weeks. You just need to get them a password somehow, and security takes a backseat to "just make it work."
The chicken-and-egg problem#
So you need to give a new hire credentials for a system they can't access yet, through a channel that's both secure and reachable. That's genuinely hard. Look at the constraints:
- No work email (you're provisioning it)
- No SSO (that's the whole point)
- Two-week gap between account creation and first day
- IT does this hundreds of times a quarter
- Auditors want receipts
Most teams look at this list and go "welp" and open Slack.
The five workarounds everyone uses#
The Slack DM. IT generates a password, messages it to the hiring manager, manager forwards it to the new hire's Gmail. Three copies of a plaintext password floating around forever. Searchable. Anyone with Slack admin access can pull it up.
The birthday password. FirstnameLastname122587! or CompanyName + last four of SSN. Every new hire gets the same formula. Figure out the pattern once, and you can guess credentials for anyone.
The spreadsheet. A Google Sheet called "New Hire Passwords Q2" that was "temporary" three years ago. It's shared with a group that's accumulated 40 people nobody audits.
The day-one phone call. Skip the initial password entirely, have the new hire call IT on their first morning. Secure, sure. But 30 minutes per person, and when you're onboarding a class of 50 that's two and a half days of someone doing phone resets. Terrible first-day experience too.
These all exist because nobody built real plumbing for this. So people improvise. And "improvise" in security usually means "accept the risk and move on."
We got tired of watching this happen, so we fixed it.
What we actually built#
We broke it into three steps that chain together in an automation. Nothing fancy about the concept -- generate, set, deliver. The interesting part is how each step works.
Generate a real password#
First step creates a random password against a configurable policy. Length, complexity, character classes, dictionary word exclusion. Not Welcome123!. Not someone's birthday.
The password gets encrypted immediately. It never shows up in plaintext in logs or the automation history. It's an opaque token that the next steps can reference but nobody can read.
Set it on the account#
The password goes to the connector -- AD, Entra ID, Google Workspace, Okta -- during account creation. It's double-encrypted on the way there: once with the platform's key, then re-encrypted with the connector's own public key before it leaves. The connector decrypts locally.
C1 never holds the plaintext password and the connector's key material in the same place at the same time. This was a deliberate design choice, not an accident.
Deliver it without Slack / Email (the fun part)#
This is where Paper Vault comes in. Instead of emailing the password, the automation drops it in a temporary encrypted vault and spits out a share link.
The link looks like: https://your-tenant.conductorone.com/secrets/view/BKRT-MFNX-DPLW
That consonant-only code is easy to read over the phone if you ever need to. When the new hire opens it, they verify who they are -- either through SSO (Manger flow), or an expiring link via email verification. For brand-new hires with no existing identity, the link itself is the auth and its single-use.
Once they're verified, the vault decrypts the password server-side, and the browser shows it. Plaintext never crosses the wire.
Then the vault burns. One view. 72-hour expiry (configurable).
Beyond day one#
Paper Vault is for the one-time handoff. But some credentials stick around -- database passwords, API keys, shared service account creds that a team needs ongoing access to.
That's App Vault. It ties a credential to an entitlement: you have the "MongoDB Production Read" grant, you can open the vault. Lose the grant, lose access. The credential stays, but who can see it is always tied to who's currently authorized.
Between Paper Vault (one-time delivery) and App Vault (ongoing access), you cover the full lifecycle without anyone resorting to a Slack DM.
