the shadow IT that IT built

The conventional shadow IT story casts the IT team as the victim. Employees go around IT. Employees buy tools on credit cards without approval. Employees ignore the procurement process. Employees install OAuth integrations without asking. IT is the central authority that would prefer visibility and governance, and every act of shadow IT is a violation of the governance IT wants to impose.

This is the story IT teams tell about themselves. It is also, in a meaningful fraction of cases, inaccurate. A substantial portion of the shadow IT in most mid-market companies was introduced by IT itself.

A head of IT, under pressure to solve a specific problem, bought a tool without running it through the governance process they would have required of anyone else. A senior IT engineer, troubleshooting an incident, signed up for a monitoring service with their personal card. A security lead, evaluating a SaaS security tool, authorized broad OAuth scopes for a trial that turned into permanent usage. The IT team, migrating to a new system, brought in a transition vendor with admin-level access that outlasted the migration.

Each of these decisions was reasonable at the time. Each of them produced a tool, an integration, or a standing access arrangement that sits in the company’s environment without going through the same governance the IT team would have demanded for a business user’s equivalent decision.

This essay is about that specific pattern, the shadow IT introduced by IT, and why it’s usually the hardest category to see and clean up.

the pressure and the exemption

The IT team’s job is to keep things running. When something is broken, the IT team is on the hook. When something new is needed, the IT team is expected to provide it. The speed at which the IT team can procure, deploy, and support tools is a direct driver of the team’s perceived effectiveness.

The governance the IT team imposes on everyone else, the procurement process, the security review, the contract review, the vendor management assessment, is slow by design. The slowness exists to reduce risk. It also reduces speed.

When the IT team itself needs a tool, the team has options that other teams don’t. The team can self-approve, because the team is the one that defines what “approved” means. The team can skip the security review, because the team includes the security function or has close ties to it. The team can purchase directly, because the team typically has its own budget and doesn’t need to route through procurement.

These options don’t get used for everything. For a major platform purchase, even the IT team goes through the full process. For a small tool, a targeted integration, an emergency purchase during an incident, or an evaluation that turns into production usage, the shortcuts are common.

The cumulative effect is that the IT team has its own shadow IT, a portfolio of tools, integrations, and arrangements that entered the environment through IT-internal channels, bypassing the governance that IT would have imposed on anyone else.

the rules IT sets, and the exemptions it takes

what IT asks of others

the policy

• Every tool behind single sign-on
• New tools go through approval
• Access is reviewed and removed

what IT grants itself

the pressure

• Admin consoles with their own logins
• Trials started during an incident, never closed
• Emergency access left on after the emergency

the IT tool stack has its own sprawl

Most IT teams at mid-market companies use a stack of tools that roughly includes: monitoring (Datadog, New Relic, Grafana), incident management (PagerDuty, Opsgenie, Incident.io), ticketing (Jira, ServiceNow, Linear), endpoint management (Jamf, Intune, Kandji), identity (Okta, Entra, Google Workspace admin), network (Tailscale, Cloudflare, vendor-specific network tools), security (endpoint protection, DLP, SIEM), infrastructure (AWS, GCP, Azure consoles and their many sub-services).

Each of these categories has multiple vendors. A mature IT team may use several tools in each category, either because different tools serve different subsegments (endpoint security for Macs vs. Windows), because of migration states (old SIEM, new SIEM, both still connected), or because the team experimented with alternatives and didn’t fully commit to one.

The stack is known to the IT team, in the sense that somebody on the team can name all the tools if pressed. The stack is documented in variable quality, ranging from well-maintained runbooks to wiki pages that are out of date by eighteen months to nothing at all.

The stack is typically not documented in the same inventory as the business SaaS tools. It lives in the IT team’s internal notes, not in the vendor management system or the SSO integration list. Which means that when the company’s CISO asks for a SaaS inventory, the IT stack is often missed, because the inventory is assembled by IT from the business-SaaS perspective and the internal tools are a separate conversation.

The internal tools have the same identity problems as the business tools. Connected apps with OAuth scopes. Service accounts with elevated privileges. Long-lived API tokens. Third-party integrations with admin access. Ex-employees who still have access because offboarding didn’t reach the internal stack.

The IT team has a blind spot for its own stack that’s structurally similar to the blind spot business teams have for theirs.

the trial that became the critical system

A specific failure mode: the evaluation tool that never got evaluated.

An IT engineer identifies a gap, logging for a specific system, or observability for a new service, or a specific security analysis. The engineer finds a tool that appears to address the gap. The tool offers a free tier or a trial. The engineer signs up, configures the integration, and starts using the tool.

The tool works. The engineer becomes dependent on it. Other engineers on the team start using it too. The tool becomes, over six to eighteen months, a critical part of how the IT team does its job. At some point, the trial either becomes paid (often on a small team plan, paid with a corporate card) or the tool is usable enough on the free tier that a formal purchase isn’t necessary.

The tool was never formally approved. It was never security-reviewed. It may not have been contract-reviewed. The data it ingests (logs from production systems, for example) includes sensitive information. The access it has to the environment is typically broad, because that’s what the tool needs to function.

The tool is now essential. Removing it would cause operational pain. Formalizing it, routing through procurement, running the security review, negotiating an enterprise contract, would force the kind of rigor that the team skipped when the tool was a trial.

So the tool sits in the stack, informally adopted, essential in practice, with the kind of access it would never have been granted if someone had reviewed it formally before it went live.

This pattern is common. Most IT teams have at least one of these tools in their stack. Identifying them requires a specific kind of honesty, because the tool is typically being used by the people who would need to flag it.

the vendor that came in with the product

When a company buys a major platform, a new HR system, a new ERP, a new CRM, the purchase usually comes with an implementation vendor or an integration partner. The implementation requires deep access to the company’s environment. The implementation vendor gets admin-level access to the target system and, often, admin-level access to adjacent systems for integration work.

The implementation completes. The contract may continue as an ongoing support arrangement, or may end. The implementation vendor’s access, at the admin tier, remains in place, because nobody has explicitly revoked it.

This pattern was discussed in an earlier essay about contractors. The specific case for IT is that the implementation vendor was brought in by the IT team itself. The vendor’s access is, in some sense, an extension of the IT team’s access. The IT team is responsible for managing it.

In practice, the IT team often loses track. The engineer who worked with the implementation has moved on, or the team has been reorganized, or the vendor’s personnel has turned over. The admin accounts on the target system, granted to the vendor’s team, remain configured. Nobody on the current IT team can confidently say which of those accounts should still exist.

A mid-market company that has deployed three major platforms over five years, each with an implementation vendor, typically has residual implementation-vendor access across all three target systems. Removing the access requires proactive cleanup. The cleanup is usually not part of the implementation completion checklist, because implementations don’t have completion checklists that include identity hygiene.

the after-hours emergency access

A specific category of IT shadow access: the access granted during an emergency and never rolled back.

It’s 2 a.m. A critical system is down. An on-call engineer is troubleshooting. The engineer needs access to a system they don’t normally touch, a database, a cloud console, a third-party admin panel. Access is granted through whatever is fastest. Maybe the engineer’s personal account gets admin added temporarily. Maybe a senior engineer shares credentials. Maybe a break-glass account is used.

The emergency resolves. The system is restored. The engineer goes to bed. The access granted at 2 a.m. was supposed to be temporary, pending a formal review in the morning. The formal review does not happen, because the urgency has passed and no process is tracking the access.

The access persists. The engineer, who had admin on a system they don’t normally have admin on, still has admin. The shared credentials, still in a messaging thread, remain valid. The break-glass account, which was supposed to have its credentials rotated after use, is still configured with the same credentials.

Every significant incident produces one or more of these arrangements. Over time, the accumulated emergency access is a meaningful fraction of the overall access graph. Removing it requires post-incident hygiene that few companies enforce.

The incident retrospective typically focuses on what caused the incident and what technical changes would prevent recurrence. Identity cleanup, revoking the temporary access, rotating the shared credentials, resetting the break-glass account, is rarely on the retrospective agenda. The postmortem is done before the cleanup is done, which means the cleanup never happens.

the tool used only during migrations

Another IT-specific pattern: the tool that was purchased for a specific migration and remains in the stack after the migration.

Migrations are time-bounded. A company decides to move from Tool A to Tool B. The migration requires a specialized tool, a data migration platform, a parallel-run system, a sync utility. The specialized tool is purchased for the duration of the migration.

The migration runs. The specialized tool does its job. The migration completes. The specialized tool is no longer needed.

The specialized tool is not canceled. The contract, which was annual, renews automatically. The tool’s integrations, which had access to both the old and new systems during the migration, remain configured. The tool continues to hold credentials for systems it no longer needs.

A year later, nobody on the IT team remembers that the specialized tool was supposed to be decommissioned after the migration. It’s still in the stack. It’s still being paid for. It still has credentials to historical systems.

This pattern compounds when the original migration engineer leaves the company. The engineer was the only person who understood the migration-specific tooling. The replacement engineer inherits a stack that includes the migration tool without understanding why it’s there. Over time, the migration tool becomes an unexplained dependency that nobody wants to remove for fear of breaking something.

where IT's own shadow IT hides

• the trial that became criticalnow holding production data
• the vendor's agentinstalled with the product, never reviewed
• after-hours emergency accessa break-glass account nobody closed
• migration toolingused once, still connected
• monitoring and ticketingusually in SSO, sometimes not
• personal admin tokenscreated by one engineer for convenience

often still openusually handled

the cleanup the IT team needs to do on itself

The audit for IT-introduced shadow IT has the same mechanical steps as the audit for business-side shadow IT, applied to a different target set.

List every tool the IT team uses that is not in the official SSO integration list. This includes monitoring tools, incident management tools, observability platforms, specialized administrative utilities, emergency access systems, migration tools, and any other tool that the team uses to do its job.

For each tool, answer: who owns it? What does it do? What data does it touch? What access does it have? When was it last reviewed? Is there a contract? Is it in the vendor management system?

For tools without clear ownership, assign an owner. For tools without documented purpose, document the purpose or decide whether to remove the tool. For tools with standing access that’s broader than currently needed, reduce the access.

List every service account, API token, and OAuth grant that the IT team itself has established. Review each one. The same questions, ownership, purpose, access, scope, apply. Tokens without owners get reassigned or revoked. Grants without purpose get revoked.

List every contractor or vendor relationship where the IT team is the internal sponsor. Review the engagement status. Revoke access for completed engagements.

This is the IT team auditing itself. It is organizationally harder than auditing other teams, because the auditor is implicated in the findings. A clean audit requires a willingness to admit that the team has not been holding itself to the standards it holds everyone else to.

The alternative, continuing to operate a stack of tools that bypasses governance, is the status quo for most mid-market IT organizations. The status quo produces the kind of residual access, standing grants, and undocumented integrations that show up in every post-breach analysis.

the exercise

Here is the specific exercise.

Write down, from memory, every tool the IT team uses to do its job. Don’t look at any lists. Just write.

Then pull the list from your primary identity provider of SSO-integrated applications. Compare your memory list to the SSO list.

For every tool on your memory list that’s not in the SSO list, investigate. Why isn’t this tool in SSO? Is it on a separate auth? Is it a trial that never got formalized? Is it a tool introduced during an incident that never got cleaned up?

For every tool in the SSO list that’s not on your memory list, investigate from the other direction. Why did you forget this tool exists? Is it still in use? Who is using it?

The reconciliation between memory and reality, inside the IT team, is the audit you owe yourselves. If you find yourself with a long list of tools you forgot you were running, or tools you introduced without governance, the shadow IT problem in your company is not primarily a business-user problem. It’s an IT-team problem.

The first governance you need is the governance of your own portfolio. After that, the governance you impose on everyone else will be more credible.

Clean up your own shadow first.