There’s an old leadership fantasy that goes something like this: The CISO surveys a sprawling technology estate, discovers 11 tools doing the work of four, calculates the licensing savings, selects a shiny new strategic platform and declares that consolidation has begun. Six months later, all 11 tools are still running. The new platform is now number 12.
I’ve seen variations of this throughout my career, from financial services to media to technology companies. At CME Group, I eventually gave myself an unofficial title: chief decommissioning officer. The job was considerably less glamorous than the acronym suggested. I had to find technology that had overstayed its welcome, identify who believed they still owned it, determine who actually depended on it and, occasionally, put a bullet in its head.
Buying technology is easy. Killing technology is hard. Tool sprawl is rarely just a technology problem but rather an organizational psychology problem. The industry’s solution has traditionally been consolidation. Buy a platform. Standardize the stack. Reduce vendors and centralize procurement. While all sensible ideas, consolidation efforts routinely stall somewhere between the PowerPoint slide and production.
Why? Because changing the toolset is easy. Whereas changing mindset is far more difficult.
You cannot Jedi mind trick an engineering team
Executives like what is called the “message from the top.” The CEO says security matters. The CIO says everyone will standardize. The CISO announces the strategic platform. Procurement renegotiates contracts. Meanwhile, Gartner produces a quadrant that reassures everybody that the chosen vendor inhabits the correct geometric region. All is well in the world of golf course nepotism.
Then reality arrives. A developer says the new scanner takes 12 minutes longer. A marketing manager has a revenue-generating legacy API they depend on. Exception requests have been filed for several years to allow this tool to continue to exist despite the packages supporting it being end-of-life and receiving no security updates. This is where the “message from the middle” matters.
Transformation does not happen exclusively in boardrooms and fusion teams. It happens in the layer of engineering managers, architects, product owners, security engineers and operations leaders who determine whether the policy announced upstairs becomes the behavior practiced downstairs. Every layer of the org chart is ostensibly trying to do the right thing and make things better. But top-down politics and bottom-up initiatives seldom find one another standing on common ground.
Ignore the middle layer of the org chart and your consolidation project becomes a rather expensive exercise in shelfware. This is something I learned working in European organizations, where consensus building carries more organizational weight than the command-and-control instincts common in American corporations (the Nike-inspired management philosophy of “Just Do It!”). You may have the authority to make a decision without possessing the organizational permission (or “rubber meets the road” context) required to make it stick or worthy of implementation.
Good chief decommissioning officers need a mixture of Jedi and Machiavellian skills. We need persuasion, coalition building, incentives, selective pressure and occasionally the ability to convince people that the idea you desperately need them to support was their idea all along. These are, in fact, the droids you’re looking for.
Every tool comes with an identity
The Star Wars metaphor becomes more useful when we stop thinking of security products as software. Modern security tools have volition and intent. They have:
- API keys
- Service accounts
- OAuth grants
- Cloud permissions
- GitHub access tokens
- CI/CD integrations
- Slack bots
- Webhooks
- Database credentials
- Kubernetes roles
- Machine identities and,
increasingly, AI agents are acting with pervasive and persistent delegated human authority.
Every time we introduce security products, we birth another highly privileged account. The industry talks endlessly about human identity. Who is this person and what are they allowed to access? We are decidedly much less disciplined about delegated identity. What is this application allowed to do on behalf of Mike? What is this scanner allowed to read from GitHub? What repositories can this integration modify? Which credentials did we give the old vendor three years ago? And the increasingly important question: when an autonomous agent acts, whose authority is it actually exercising? This changes the economics of tool sprawl. The cost of the twelfth security tool is not merely another annual subscription. It is another (potentially misbegotten) trust relationship.
This is why I’m advocating decommissioning as a core security discipline. Technology organizations suffer from an immortality bias. I gave a “Top-Rated Session” on this topic at RSAC in the spring. We have sophisticated processes for creating things and surprisingly primitive processes for making them disappear. The software development lifecycle is usually illustrated as planning, design, development, testing and deployment. The diagram often ends there, as if every application ever deployed subsequently lives happily ever after. It does not.
Consolidation without decommissioning is multiplication
I’m skeptical when vendors promise “platformization” will solve tool sprawl by itself. A platform strategy can absolutely make sense. Fewer vendors can mean lower licensing costs, fewer integrations and consistent data with less operational complexity. But purchasing a platform does not consolidate anything by itself. Removing the old systems does. That sounds obvious, yet many organizations measure successful consolidation by contracts signed rather than systems eliminated.
Imagine replacing three tools with one platform but leaving all three products technically operational “temporarily.” The service accounts remain. Someone still logs into them. Congratulations! You’ve not consolidated four tools into one but instead consolidated three tools into four. This distinction becomes important as security products gain autonomous capabilities. Yesterday’s forgotten dashboard becomes tomorrow’s forgotten agent with permission to take actions. A zombie application is bad enough, but a zombie application with agency is worse.
Ask the people who actually use the droids
The antidote is not stronger central control but rather explicit ownership. RACI matrix much? Before replacing a tool, find the people who use it and ask an embarrassingly simple question: “What do you actually use this for?” Don’t ask what the contract says. Don’t trust what the architecture diagram might show (*do* check the last modified date, though).
Take what the vendor’s customer-success representative believes with a grain of salt and more than a modicum of skepticism. What do people actually do with it on Tuesday morning? Security leaders are usually surprised by the answer. Maybe the vulnerability scanner’s primary value is not vulnerability scanning. Perhaps an engineering team depends on an obscure export function for its weekly metrics. Maybe the old SIEM has one correlation rule tied to a regulatory requirement that hasn’t been migrated. You will find these things if you look.
This is where the middle of the organization becomes your real intelligence network. The people closest to the systems know where the undocumented dependencies live. Treated as obstacles and they’ll defend their tools. But allow them to be participants and they’ll help dismantle them. A good perspective when planning to kill someone’s baby is to help them understand that they fell in love with the control the tool gave them over the chaos that reigned before it was implemented. And that a new tool can be equally comfortable and easier to support than the burden of the care and feeding that most “heritage” (I prefer this term to “legacy”) applications and solutions require.
Ownership should include the power to recommend retirement. One of the healthiest metrics an organization could create: number of tools and integrations it successfully eliminated this year. We celebrate deployment. Why don’t we celebrate deletion?
The CISO as chief decommissioning officer
Every CISO needs to spend time as CDO. Not chief data officer. Chief decommissioning officer. The role requires asking uncomfortable questions because almost every incentive in technology encourages addition. Nobody gets a press release or a promotion for turning something off. But resilience is partly subtractive.
Every redundant vendor removed is one less company holding your data and one less administrative console an attacker can target and breach. Our industry spends billions asking, “What else should we deploy?” Mature organizations also ask, “What can we safely eliminate?” That second question becomes much more important with agentic AI.
We’re rapidly filling enterprises with digital droids acting on behalf of humans. Regardless of function, almost all require credentials and delegated authority. Organizations that manage this transition successfully will not merely know how to authorize these identities; they will rotate and revoke them automatically. Leadership therefore needs both a message from the top and a message from the middle. The top establishes direction and the middle supplies reality.
Bring the people doing the work into the decision. Make sure your fusion team tasked with consolidating 77 dashboards is comprised of old guard leaders as well as young blood new hires. Strive to understand the dependencies, functional requirements (antiquated as they may be) and non-functional requirements such as availability, integrity and confidentiality. Define what successful retirement looks like before buying the replacement.
Don’t ‘move along’
The next time someone arrives with a miraculous new platform promising to eliminate half of your stack, resist the urge to wave your hand and say, “These aren’t the droids we’re looking for.” They may well be. But before buying more droids, find out who owns the ones already wandering around your Death Star. Find them. Name them. Understand what authority you gave them. And when their mission is finished, dare to switch them off. Create a technology graveyard on your wiki, Confluence or SharePoint site and celebrate the addition of decommissioned tools and technologies with even more fervor than those which have just recently sprung into existence.
