This blog focuses on Entra ID TAP to explore passwordless user onboarding. It's not assuming only Entra ID or TAP can handle it.
You've seen this movie before; hell, you've probably directed it. A new hire signs their offer, HR provisions them in the HRIS, and somewhere between the welcome email and their first standup, someone in IT generates a password for them (or you could have C1 generate it securely). Maybe it lands in the welcome email. Maybe it gets read aloud on a Zoom call. Maybe it's ChangeMe123! with a smiley face.
That password is the weakest credential this person will ever hold. Sure, they must change it during login—but they haven't enrolled in MFA, they haven't seen security training, and they don't know what your help desk's voice sounds like. That means a polite phishing call ten minutes after delivery has a real shot (low probability but never say never). And the password itself just sat in an inbox in plaintext.
Passwordless is plan B in most cases. It isn't intentional; it's just how things were—and still are. I'm not faulting anyone for doing it. It's inevitable if you have AD, non-SSO-enabled apps, or legacy apps that can't support anything else.
This is for the modern enterprise: the ones who were able to ditch AD, go cloud-only, and go SSO-only.
A short tour of how we got here#
Passwords on computer systems showed up at MIT in 1961, on the Compatible Time-Sharing System. Fernando Corbato needed a way to keep researchers from reading each other's files on a shared mainframe. They were the simplest answer to a resource allocation problem. Each researcher got a few hours of compute per week, and the password mostly kept people from hogging the machine. Security wasn't really the point.
Two things broke that model almost immediately, both in 1962.
The first was a software bug. Two CTSS admins were editing the system password file and the message-of-the-day file at the same time. The temporary editor files got swapped, and the password file got printed on every terminal at login. Robert Morris and Ken Thompson wrote it up years later in Password Security: A Case History, the same paper that pushed Unix toward one-way hashing.
The second was Allan Scherr. Scherr was a PhD researcher at MIT, allotted four hours of compute per week, which wasn't enough to finish his simulations. So on a Friday night he submitted a punched card requesting an offline print of the system password file. Saturday morning he walked over to the file cabinet and pulled the printout from the M1416 folder. He used the passwords for years, and handed them around to friends (one of whom logged in as the lab director, Robert Fano, and left taunting messages). Nobody caught on. They wrote it off as a software bug. Scherr only confessed at the CTSS 25th anniversary in the late 80s.
So the first password breach is roughly as old as the first password. Both were 1962. Neither was theoretical.
The model held anyway, because there were five systems in the world and they were all yours. By the late 90s every app had its own login. By 2010 the average knowledge worker had dozens. NIST tried to help in 2003 with Bill Burr's Special Publication 800-63, which told everyone to mix uppercase, lowercase, numbers, and symbols and rotate every 90 days. Burr admitted in 2017 that the advice was wrong. He'd written it from an unpublished 1980s white paper, the rules drove users to predictable tweaks like Password1 then Password2, and the rotation requirement made things worse. NIST formally dropped the rotation and complexity rules in SP 800-63B that same year.
Reuse became the rule, and the big credential dumps made that reuse cheap to weaponize. LinkedIn was breached in 2012. The initial estimate was 6.5 million unsalted SHA-1 hashes; the real number turned out in 2016 to be 117 million. Adobe lost 153 million the next year. Yahoo lost three billion across 2013 and 2014. The credential reuse chain ran straight from LinkedIn into Dropbox (a Dropbox engineer had reused their LinkedIn password), and from Dropbox into every other place that engineer had ever logged in. The internet became a graph of "where else did you use this string."
MFA got bolted on top of the password, and that mostly held until SIM swapping (Jack Dorsey's own Twitter account in 2019) and OAuth consent phishing caught up. Both work because the password was always the weak link, and adding a second factor doesn't repair a system whose primary factor is a string the user typed into ten different boxes that week. It was still a huge improvement nevertheless.
FIDO2 and WebAuthn arrived in 2018. Apple shipped passkey UX in iOS 16 in September 2022. Google rolled passkeys to Chrome on Android, Windows, and macOS in December 2022, and made them the default for personal Google accounts in late 2023. Microsoft started killing the password in September 2021, when consumer Microsoft accounts went passwordless-optional, and Entra ID passkey support followed through 2023 and 2024. We finally have a model where the credential lives on the device and can't be phished or forgotten.
What we don't have, in most orgs, is a way to get the new hire to that first passkey without giving them a password first.
TAP: a passcode you're allowed to use#
Microsoft's Temporary Access Pass (TAP) is a time-bounded, single-use (or limited-use) passcode you issue to a user from Entra ID. They sign in with it, register a passkey or Windows Hello credential or Authenticator app, and the TAP is done.
It looks like a password because it's a string. It doesn't behave like one. You set how long it's valid (10 minutes to 30 days), whether it works once or repeatedly within that window, and which authentication policies accept it. After enrollment, the user has real credentials and the TAP is dead.
So, the question on day one stops being "what password do we send" and becomes "how do we get a TAP into the new hire's hands the second HRIS says they exist."
Wiring it up in C1#
C1 fires workflow automations off of lifecycle events from the source of truth, usually an HRIS. So when Workday creates a new worker record, the joiner workflow runs. And then our TAP function can be a step in that workflow to enable TAP, and hand it off to the email step which then sends it to the user.
Generating a unique email takes a display name and a domain, derives a username (dot, dash, or underscore separator; lower, upper, or capitalized case), and checks C1/IdP to make sure the address isn't already taken. If jane.doe@company.com exists, it tries jane.doe1, and so on. No collision-handling logic needs to live in the HRIS. This is a sample algorithm; you can fully customize what you want it to be.
Once the user has been created in Entra ID with that UPN, our TAP step function calls the Graph API and returns a TAP. The default is an 8-hour, single-use pass. You can extend it (up to 30 days) or switch to multi-use if the new hire's first day is a week out and you don't want to time the delivery precisely.
Our email step can then send the email to the user's personal email, the manager, or the IT team (it can send it to all for all we care!). The email contains the TAP, the sign-in URL, the expiration, and short instructions: go here, paste this, register a passkey. No password to remember, no password to forget, no password to phish. Fully automated and customizable.
If Workday needs the new work email afterwards, then we can write it back through the Workday SOAP API. The HRIS, the IdP, and the new hire all converge on the same identity without a help desk ticket in between.
End-to-end:
Workday joiner event
-> C1 workflow trigger
-> generate unique email (build a unique UPN)
-> create Entra user (via Entra connector provisioning)
-> create Entra TAP (issue time-bounded pass)
-> send email (deliver to personal email)
-> update Workday (sync work email back to HR)
No reading aloud a password. No need to change a password. Passwordless on day one.
Conclusion#
The new hire's first credential is one they enrolled themselves, on hardware you can attest, behind whatever conditional access policy you want to layer on top (by the way, we can also help you automate the equipment ordering flow). Your help desk stops being the password-reset desk for week-one folks. Your audit logs stop showing initial passwords. The "shared password in email" attack surface goes from headcount per year to zero.
That's it. The day-one password is a habit, not a requirement. You can stop.
