The Keys to Everything: What Happens When a Trusted Admin Goes Rogue
Most organizations spend the better part of their security budget thinking about the threat that comes from outside. The nation-state actor, the ransomware gang, the phishing campaign that gets through. Those threats are real and worth defending against.
But there is a different threat sitting inside almost every organization, one that gets almost no structural attention until it is too late. It is not a vulnerability bypassing the firewall. It is a person, a trusted, competent, indispensable person. One who, over time, has accumulated access to, or was responsible for acquiring nearly everything from the chosen business platform (M365 or GSuite), the domain registrar, the DNS management console, the cloud hosting environment, every client portal and admin console the organization operates. The person who knows where all the bodies are buried because they helped bury them.
When that person decides to burn it down, the damage happens fast. This is what that looks like.
The Setup
Every organization has one. The swiss army knife. The trusted person who gets called when something breaks in the middle of the night. The one who set up the email system, migrated the infrastructure, onboarded clients, and over years quietly became the single point of contact for every critical system the business depends on. Their access grew organically with their responsibilities. Nobody sat down and decided to give one person the keys to everything. It just happened, because they were good at their job and they were trusted.
The title varies. VP of Delivery Operations. CTO. Senior Systems Architect. Sometimes it is a long-tenured managed services engineer who has been around long enough that their access was never revoked as the organization grew. The common thread is competence that was rewarded with trust, and trust that was expressed as access.
What the First Twelve Hours Actually Look Like
The message arrives on a Tuesday. It could be a text, an email from a personal account, or a formal letter delivered through an attorney. The demand is specific: a severance payment, an equity buyout, a non-disparagement agreement with teeth, or simply a dollar figure. The message makes clear that the sender has administrative access to systems the organization cannot afford to lose, and that they intend to use it if the demand is not met.
The clock starts there.
Within hours, the M365 tenant begins to show anomalies. Global admin accounts being disabled. Password reset policies are changed. Multi-factor authentication methods are modified so that recovery codes go to devices the organization no longer controls. Email stops flowing. Teams goes dark. The organization's primary communication infrastructure is offline.
The domain registrar account is accessed and the nameserver records are changed. The organization's domain now resolves to nothing, or to a parking page, or to whatever the departing admin decides. The website is gone. Email delivery is broken at the DNS level even if the tenant were recovered. Every subdomain that pointed to a client portal, a ticketing system, a scheduling tool, a support page, all of it is now pointing nowhere.
Cloud-hosted resources begin disappearing. Storage buckets are emptied or deleted. Virtual machines are terminated. Databases are dropped. Backups, if they were stored in the same cloud account, are gone. If the organization's website was hosted on a managed platform and the admin had owner-level access to that account, the site is deleted. Years of content, gone in minutes.
Every other user access has been removed or locked out. The IT director tries to log in and cannot. The COO cannot access email. The CEO is sending text messages from a personal phone because the corporate system is offline and nobody knows when it is coming back.
The only communications available are the ones that never ran through the compromised infrastructure. Phone calls. Text messages to personal numbers. Physical mail. FedEx. The organization is functionally dark to every client, vendor, and partner who depended on digital contact.
This is not a hypothetical scenario. Versions of it happen regularly, and they are more common in smaller and mid-market organizations precisely because those organizations are more likely to have relied on a single trusted resource rather than building structural controls.
Why the Swiss Army Knife Is a Structural Risk
The instinct when something like this happens is to frame it as a personnel failure. The person was unethical. The person was unstable. The organization should have seen the signs.
That framing misses the actual problem. The risk is structural, not personal. It exists regardless of how trustworthy any individual seems, because circumstances change. Employment disputes escalate. Equity conversations go badly. Personal financial stress reaches a tipping point. Mental health deteriorates. Business partnerships dissolve in acrimony. A person who was genuinely trustworthy for a decade can become a genuine threat in a matter of weeks when the circumstances are right.
The structural failure is allowing any single person to accumulate the access necessary to execute total destruction. That failure is common because it develops gradually, because it feels efficient, and because it does not create a visible risk until the moment it does.
The access that matters most is not application-level access to individual systems. It is the foundational layer: the domain registrar, the DNS management console, and the identity platform that governs all other access. Whoever controls those three things controls everything downstream. If one person can change the nameservers, disable the tenant administrator accounts, and delete the cloud backups, no other control matters.
How Organizations With the Most to Lose Solve This
Fortune 250 companies do not have this problem at the catastrophic level for a reason that has nothing to do with technology. They solve it through structural separation of authority that is tied to role, not individual competence.
The credentials for the domain registrar are not held by an engineer or technical person. They are held by general counsel or the chief legal officer, registered to a legal entity rather than an individual, and the contact information on the account resolves to a legal department address. The attorney has professional obligations, bar association liability, and no operational motive to destroy the infrastructure they are safeguarding. The engineer who manages the DNS day-to-day has delegated access to change records, but they do not have the ability to change the nameservers or transfer the domain, because those actions require credentials they do not hold.
The cloud provider accounts follow the same model. There is an ownership-level account tied to a corporate identity with billing authority, and there are operator-level accounts that can do almost anything except delete the ownership account or change the billing entity. The ownership account credentials are stored physically, distributed to two or three named individuals who have significant personal and professional stake in the organization's survival — a C-suite executive, general counsel, a significant equity holder.
The identity platform; Microsoft 365, Google Workspace, whatever the organization depends on, has break-glass emergency accounts that are not known to any operational staff. Those accounts exist specifically for recovery scenarios. The credentials are stored offline, in a sealed physical document, accessible to two named executives who require both signatures to open it. No engineer knows the password.
The principle behind all of this is simple: separate the ability to operate from the ability to destroy. Every operator needs access to do their job. Nobody except the ownership layer should have the unilateral ability to delete the organization's digital existence.
The Role That Actually Holds the Keys
The question organizations need to answer is: who in your organization has enough at stake that they would never use administrative access as leverage? The answer is almost never an engineer, because engineers can get another job. The answer is usually someone with equity, legal exposure, long-term financial stake, or professional licensing that creates real personal consequences for misuse.
General counsel is the gold standard. An attorney who misuses access to client or corporate systems faces bar discipline and personal liability, not just termination. The consequence structure is entirely different from that of an employee who can simply walk out the door.
A COO or CFO with significant equity in the organization has financial skin in the game that makes destructive action self-defeating. They destroy the organization, they destroy their own net worth.
A board member or significant investor holds access as a fiduciary, not as an employee relationship.
None of these people need to understand how to manage DNS records or configure an M365 tenant. They need to hold credentials that nobody else can access, with instructions for when and how to use them. They are the circuit breaker, not the electrician.
What a Privilege Architecture Review Actually Covers
For most mid-market organizations, the starting point is an honest audit of who holds what. The questions that matter:
Who are the global administrators on your Microsoft 365 or Google Workspace tenant, and what would happen if those accounts were disabled simultaneously? Do break-glass accounts exist, and if so, who holds those credentials and where are they stored?
Who holds the login credentials for your domain registrar? Is that a personal account, a shared account, or an account tied to a role? What happens to those credentials if the person holding them leaves tomorrow?
Who has owner-level access to your cloud provider accounts (AWS, Azure, GCP, OCI)? Can that access be used to delete resources rather than just manage them? Who could terminate your backups?
What would it take to completely recover your communications infrastructure from a dead stop, and who has the authority and the access to initiate that recovery?
The answers to those questions define the actual blast radius of a rogue admin scenario. For most organizations, the answers are uncomfortable. The fix is architectural, not technical — it requires putting the right access in the hands of people with the right incentive structure, not just the right skill set.
That conversation is worth having before the Tuesday message arrives, not after.