If you are reading this at nine o’clock on a Friday night, take a breath. Your business still owns everything it owned yesterday. You have lost the key, not the house. Here is the order to work in, with the documented vendor paths, verified September 23, 2026.
The first hour
Stop guessing passwords. Repeated failed sign-ins trigger lockouts and fraud holds that make real recovery harder.
Do not let anyone shut anything down. Running equipment holds a configuration you may not be able to rebuild. A reboot that asks for a password you do not have turns a problem into an outage.
Write down what you control. Which accounts can you sign into right now? Who receives your technology invoices, and whose card do those charges hit? Those invoices are your map. They tell you which accounts exist and who each vendor believes is in charge.
Check for a door that is already open
Is there a second administrator? An office manager, a bookkeeper, or a previous technician may still hold a role nobody has thought about in years. A prior IT firm may also still hold delegated administrative access, which is a working door if nobody ever removed it.
Did you buy through a reseller, partner, or web host rather than directly? This is the highest leverage question, and most owners get it wrong. Microsoft’s documentation says that if you bought all your subscriptions through a partner, you contact the partner, not Microsoft. Google’s troubleshooting page leads with “Did you buy Google Workspace from a reseller?” and tells you to ask them for your administrator credentials. If your bill comes from a company that is not Microsoft or Google, call that company first.
Microsoft 365 and Entra ID
Microsoft has an automated takeover path, but it covers a narrower case than most people assume.
If your tenant is unmanaged, you can self-serve. Microsoft defines an unmanaged tenant as one with no Global Administrator at all, which happens when employees signed up for a free or trial service on their work email and nobody ever claimed the directory. The documented takeover: create a user context on the domain, sign in at portal.office.com/admintakeover, choose “Yes, I want to be the admin,” then prove domain ownership with a TXT record at your registrar. The record looks like MS=ms18939161, goes on the parent domain, and Microsoft recommends a TTL of 3,600 seconds. Propagation “can be instantaneous or it can take a few days, depending on your domain registrar,” and Microsoft advises waiting at least an hour before retrying. Enter it wrong and you wait out the TTL.
If your tenant is managed and the Global Administrator has simply left, that path does not apply. Microsoft publishes no self-service recovery for a managed tenant whose only Global Administrator is unreachable. Its own emergency access documentation names this scenario and says either situation “might make the organization unable to recover the account.”
Your route is a support case, not a wizard, and there are two obstacles. Microsoft’s documentation says you must be an admin to use its support methods, and if you call from an unregistered number, the representative sends a verification code to the contact details on file in your admin center profile, which is exactly what you cannot reach. Call anyway, with your domain, tenant name, billing records, purchase details, and entity documentation ready. Microsoft publishes no timeline, so treat any turnaround figure you read in a forum as unverified.
Do not count on a password reset alone. Administrator accounts sit on a two-gate reset policy Microsoft says cannot be changed, requiring two separate pieces of authentication data. If the departed person registered only one and it lives on their phone, Microsoft says the result is “unable to reset or unlock,” with the instruction to ask an administrator. That is circular when there is no administrator.
Google Workspace
Google documents a path written for exactly this situation. Its “Can’t sign in to the Admin console” page has a section titled “Original admin left company and no one has access,” and it sends you to the Admin console login issues form at toolbox.googleapps.com/apps/recovery/form.
A current employee with an active account on your domain signs in as themselves, enters the domain, selects “I am a user and cannot contact my administrator,” and receives a support reference number by email. Add a CNAME or TXT record at your registrar to prove domain control, then submit a request for user promotion. Google’s documentation says: “If the administrators are inactive and unresponsive, Google will promote your user account.” It does not publish how long it waits before deciding that.
If you are resetting the super administrator’s own password instead, that flow uses a CNAME record: the host is the unique string the recovery wizard gives you, the target is google.com, TTL 3,600. Google says CNAME changes “can take up to 72 hours to go into effect,” and that if the record is not found within 48 hours you get an email saying recovery failed.
One trap. Google turns super admin self-recovery off by default on several editions, including Business Plus, Frontline Standard, Education Standard and Plus, Enterprise Essentials Plus, G Suite Basic, and Cloud Identity Premium. On those, “Forgot password?” just tells the admin to contact their administrator, so the form is your route.
Gather evidence first. Google asks for the account creation date, the original signup secondary email, your order number, user count, billing address, and the card type and last four digits. The welcome message from [email protected] is worth digging for. One clock to watch: Google says a deleted user, including an administrator account, can be restored for up to 20 days. After that the data is gone.
Your domain and DNS
Do this in parallel, because everything above depends on it. If you cannot add a DNS record, you cannot prove domain ownership to Microsoft or Google, and both paths stall.
Find your registrar. Use ICANN Lookup at lookup.icann.org. Under current registration data rules the registrant name and postal address are no longer required to be published, so expect redaction. The registrar still holds the real record.
Know the difference between DNS control and registrar control. If you can edit DNS records, you can keep mail and your website resolving and add verification records. That is a partial position, not ownership. Without the registrar account you cannot renew, transfer, obtain the authorization code, or change the registrant. Expiration is the wall: the ICANN Transfer Policy blocks a change of registrant once the registration agreement has expired. Find your renewal date today.
Open a recovery case with the registrar. There is no ICANN-mandated process and requirements vary substantially, so read your own registrar’s documentation. The range is wide: Network Solutions publishes a process written for claimants who “cannot reach the current primary contact,” with a stated turnaround of 24 to 48 business hours, while Cloudflare publishes no paper based recovery path at all. Assemble a general packet and adapt: formation documents, business license, tax identification, photo identification for a current officer, payment records, and prior invoices.
Know ICANN’s limits. Its own complaint page says plainly that “ICANN does not have contractual authority or the technical ability to return a lost domain name to you.” A complaint is leverage to make a non-responsive registrar follow its own published process, not a recovery mechanism. Skip the two dispute processes people reach for. The Transfer Dispute Resolution Policy is filed between registrars, not by a business. The UDRP is for trademark cybersquatting and requires proving bad-faith registration, which does not describe a domain your own contractor registered legitimately for you. Filing either freezes the changes you need.
One warning. Once a change of registrant completes, the Transfer Policy imposes a 60-day inter-registrar transfer lock unless the registrant opts out before the change is made. If you plan to move the domain into an account you control, ask about that opt-out before you accept the change, not after.
Where the wall actually is
You deserve a straight answer, because chasing an impossible recovery costs time you need elsewhere.
Encrypted disks with no escrowed key. Microsoft is unambiguous: “Microsoft Support doesn’t have the ability to retrieve, provide, or recreate a lost BitLocker recovery key.” Check your directory, any managed account tied to the device, printouts, and saved files first. If the key was truly never escrowed, the documented remedy is resetting the device, which removes all files.
Backups encrypted with a customer held key. Where the customer supplies the key, the provider does not keep it. Amazon states it plainly: “S3 never stores the encryption key when you use SSE-C. That also means if you lose the encryption key, you lose the object.”
Accounts where the only second factor left with the person. Many vendors say outright that they cannot help. GitHub warns that if you cannot use any recovery method, “you have permanently lost access to your account.” Services with an organization, a domain to verify, and a billing relationship usually have a path. Services with none of those often do not.
Government and financial portals. These get re-established in a current person’s name rather than recovered, which is the right outcome anyway. IRS Form 8822-B reports a change of responsible party, and the IRS notes that “changes in responsible parties must be reported to the IRS within 60 days.” The IRS Business Tax Account is tied to a Designated Official who must be a current officer or managing member, received a W-2 for the most recent filing year, and can legally bind the entity. For banking and payroll, plan on your institution’s documented process for changing authorized signers.
The line not to cross while fixing this
A business generally has authority over its own accounts. That is not the same as authority to use a particular person’s credentials.
The Computer Fraud and Abuse Act, 18 U.S.C. 1030, distinguishes accessing a computer “without authorization” from exceeding “authorized access.” In Van Buren v. United States, decided June 3, 2021, the Supreme Court read the second phrase narrowly, as a gates-up-or-down inquiry about areas of a system that are off-limits to you. That case involved valid credentials used for an improper purpose. It did not loosen the separate “without authorization” clause, which is the one that matters if you are tempted to sign in with a credential that is not yours.
Arizona has its own statute. A.R.S. 13-2316 opens, “A person who acts without authority or who exceeds authorization of use commits computer tampering by,” and its listed acts include knowingly accessing any computer, system, network, software, program, or data, a class 6 felony. A separate federal statute, the Stored Communications Act, 18 U.S.C. 2701, covers unauthorized access to a facility through which an electronic communication service is provided. That one bears directly on any temptation to get into a former employee’s personal email to intercept a password reset. Do not.
Practically: work through vendor processes that verify your organization’s ownership, and keep a written record of every step and of the business’s authority over each account. If the departure was contentious, or if anyone claims ownership of your domain or accounts, talk to an attorney before acting. This is general information, not legal advice.
So this cannot happen again
Every item below is a practice, not a purchase.
Hold your own administrative credentials. A current, encrypted record of every administrative account, held by the business and reachable by at least two of your people. If your IT provider maintains it, hold a copy too.
Own the registrar account in the business’s name. Not the technician’s email, not the web designer’s. The registrant is the legal entity, the contact address is a shared business address that survives anyone leaving, and someone in the business knows the renewal date.
Name a second administrator who is not the IT person. Microsoft goes further, recommending two or more emergency access accounts that are cloud only, not tied to any individual or employee-supplied device, with credentials stored separately and validated at least every 90 days and after any change in IT staff.
Escrow your recovery keys. Disk encryption keys belong somewhere the business controls, and confirm they are actually there rather than assume. Backup passphrases belong somewhere reachable without the person who set them.
Write an offboarding process and use it every time. Who is notified, which accounts are disabled, which roles are reassigned, which shared credentials are rotated, what equipment returns, and who signs off. One page, and the cheapest insurance in your business.
Test it once a year. Pick an administrative account and confirm someone other than your IT person can actually get in. A documented credential is worth nothing until you have proven it works.
Asteroid IT works with small businesses across the Phoenix and East Valley area. If you are in the middle of this right now, or if reading this made you realize you do not know where your recovery keys are, we are glad to walk through it with you. And if you work the list above yourself this weekend and never call us, that is a good outcome too. We would rather you have your keys than have our phone number.