Origin
In September Pranay, one of our founders, spent a few weeks with the first IT hire at a 160-person engineering consultancy that had run for 9 years without anyone in IT.
The first real problem arrived in week 2. Marketing needed a TXT record on the company domain for a new email service, and nobody could log in to the registrar.
The account had been opened in 2016 by a co-founder, on his personal Gmail. He'd left in 2022, on good terms. The password reset went to his Gmail, and he replied 4 days later, apologetic, from a holiday. The domain's registrant was him personally too. If he hadn't replied, getting the account back would have meant convincing the registrar that the company was entitled to a domain registered in someone else's name.
In 2016 somebody needed a domain, and he bought one.
The usual first-month exercise for a new IT hire is an admin inventory: who has admin on what. It's a useful list, and it would have missed this completely, because the co-founder didn't have admin on anything anymore. His accounts had been closed the week he left. He was just where the registrar's password reset ended up.
The question that finds this is a different one. For each account that could really hurt the company, where does its recovery end? If the person holding it disappeared tomorrow, how would the company get it back, and whose inbox or phone would the last step reach?
A password is something a person holds. Recovery decides who owns the account. Whoever controls the recovery path can take the account from whoever has the password, and at most small companies nobody has looked at those paths since the day each account was created.
Following them leads to some uncomfortable places. At the consultancy, Google Workspace had a single super admin, the CEO's everyday account, with no recovery email or phone set. For that case Google's recovery process asks you to prove you control the domain by adding a CNAME record to its DNS. Their DNS was hosted at the registrar.
So the company's email, which nearly every other password reset in the company runs through, recovered in the end to a man who'd left 4 years earlier, through his personal Gmail.
The new IT hire followed the 6 logins that could do the most damage: the registrar, the Google super admin, the AWS root user, the GitHub org owner, the Apple push certificate that lets Intune manage their Macs and iPhones, and the owner of the company 1Password account. Every one ended at a single person. 3 of those people had left.
That pattern isn't particular to them. At a company without IT, accounts get created as a side effect of getting something done, by whoever was there, on the email they had. Nobody decides who owns the AWS root user. Somebody needed a server in 2017.
None of this is covered by what most companies do about access. The consultancy had Google sign-in on most of its apps and a decent offboarding checklist, and the checklist had been followed when the co-founder left. It took away everything he could get into.
What it never asked was what could only be got back through him. Being the end of someone else's recovery path isn't access. It doesn't show up in an admin console or a group membership, and nothing about it changes when the person leaves. It isn't even visible to the person. The co-founder had no idea he still held the domain until the reset email arrived.
These accounts sit outside the identity provider more or less by definition. The registrar, the cloud root user, the Apple Account behind the push certificate and the super admin of the identity provider itself are what you'd rebuild everything else from. They're kept out of SSO on purpose, so nothing that governs SSO reaches them.
Moving a recovery path is usually easy. The trap is replacing the account instead. At the consultancy the Apple push certificate had been created by an office manager who'd since left, under an Apple Account on her own Gmail. A fresh certificate under a company account would have meant every Mac and iPhone re-enrolling, which at 160 people is a month of desk visits. Changing that Apple Account's email to a company list kept the certificate and moved the recovery. The AWS root user went the same way. The MFA device was a departed CTO's phone, and an IAM user with administrator access can change the account's primary contact number that AWS calls to recover it.
The order that matters is what can't be got back at all. A 1Password account with a single owner is gone for good if that owner loses their password or Secret Key, and 1Password can't help. Fix that one first, the same day, by adding a second owner.
We build Iden to close a leaver's access in every app on their last day, including the apps SSO never reaches. This list is a different job. It's about the handful of accounts that are supposed to outlive any one person, and no tool can choose the second person for you. What a company can do is make it part of every senior departure: ask what the person could get into, and also what only they could get back.
The new IT hire sent the list to the CEO at the end of the month, with a second name against every login that had only had one.
We'd sit down with you and follow your 6 most dangerous admin logins to the end of their recovery paths. No deck. Just the product.