A proposed bill in Colorado is raising a much larger question for enterprise IT management across the nation. The legislation, state bill SB26-090, is titled ‘Exempt Critical Infrastructure from Right to Repair’ — and it does exactly that. If approved by the Colorado House and Senate, it would carve out “critical infrastructure” from the state’s right-to-repair requirements, limiting who can service and maintain key systems.
The rationale is familiar: restrict access to sensitive equipment to reduce security risk. Supporters of the proposal argue that tighter control over repair and maintenance will protect system integrity; those supporters include vendors Cisco and IBM.
For CIOs, however, the relevance goes far beyond one state or one policy. It touches a deeper issue: who ultimately controls enterprise infrastructure once it is deployed — and who decides how and when it is fixed?
David Linthicum, founder, Linthicum Research
“This is part of a broader shift,” said David Linthicum, a cloud and AI expert and founder of Linthicum Research. “Over the last several years, large technology vendors have been trying to keep tighter control over hardware, software, support and even the data generated by those systems.”
That shift is now surfacing in policy. And as it does, it is forcing a reconsideration of a long-standing assumption in enterprise IT: that ownership of a system implies control over its operation.
Control, reframed as IT security
For much of the past decade, enterprise IT strategy has emphasized flexibility. Organizations diversified vendors, adopted cloud platforms and built architectures designed to avoid dependence on any single provider. Even where vendor lock-in existed, it was treated as a risk to manage.
The right-to-repair debate introduces a different framing. It is not about lock-in; it’s about security. Yet the outcome can look similar: tighter vendor control over how systems are maintained, who can access them and what options exist when something goes wrong.
Linthicum said he sees a convergence of incentives behind this shift. “Security is a valid concern, especially in critical infrastructure,” he said. “But vendors also know that control over repair creates control over service contracts, upgrade cycles, spare parts and customer dependence.”
Niel Nickolaisen, a technology leader advisor at VLCM and chairman of the CIO Council at FC Centripetal, questioned both the framing and the intent. “What problem are they trying to solve?” he asked. “If they could articulate that clearly and tightly define who this impacts, my skepticism would shrink.”
Without that clarity, policies risk reshaping control structures in ways that extend beyond their original purposes — for better or worse.
Where risk actually shows up
The case for restricting repair access rests on reducing the likelihood of tampering or misconfiguration. In theory, fewer hands touching critical systems means fewer opportunities for compromise. But critics argue the theory is far from reality.
“In practice, delayed access is often the more immediate operational risk,” Linthicum said. “Most enterprises already have strict controls around who can access sensitive systems. But when something fails, downtime is real, expensive and public.”
If repair is limited to vendor-approved channels, response times depend on external capacity, such as support queues, the availability of parts and scheduling constraints. That delay can turn a contained issue into a broader disruption.
Nickolaisen said he sees risk on both sides, but he questions whether vendor control meaningfully reduces it. “We have processes and tools to reduce and manage access to our systems,” he said. “If the manufacturer has access, how do I vet and control their people? Do I need to include them in my compliance processes?”
He also pointed to the practical challenge of scale. “How does the manufacturer staff the support team to provide every enterprise customer with the support it needs in the event of an outage?” Nickolaisen said. “If they are going to take control, what service-level guarantees will they have?”
Rather than eliminating risk, the shift redistributes it, introducing new dependencies even as it seeks to reduce existing ones.
Ownership without authority
At the center of the debate is a more fundamental question: What does it mean to own enterprise infrastructure? Traditionally, organizations deploy systems and take responsibility for how they are maintained and operated. Vendors provide updates and support, but enterprises decide when and how those interventions occur.
Policies that restrict repair rights begin to unsettle that model.
“The enterprise customer is responsible for evaluating patches and upgrades and deciding what to deploy and when,” Nickolaisen said. “This seems to violate those boundaries.”
If vendors — or policies shaped by vendor priorities — gain greater control over maintenance, that authority shifts. Decisions about timing, prioritization and mitigation may no longer sit entirely within the organization.
Linthicum framed the impact in practical terms: “The biggest change is the loss of operational flexibility,” he said. “Costs go up, response times can worsen, and negotiating leverage declines. But the real issue is that CIOs have fewer options.”
Those options matter most during disruption, when the ability to act quickly can determine the outcome. Without them, ownership becomes more symbolic than real.
The unintended consequences
The longer-term effects of this shift may be less visible, but no less important. While the full impact is not yet clear, the experts foresee several new complications arising as a result of this kind of legislation.
Linthicum pointed to reduced competition in third-party support, higher lifecycle costs and increased pressure to replace systems rather than repair them. “Over time, that can reduce resilience rather than improve it,” he said. “If organizations cannot act quickly and independently during outages, the system becomes more fragile.”
Nickolaisen’s concerns extend to governance and accountability. He questioned how new restrictions would interact with existing regulatory frameworks and whether they would create overlapping obligations. He also raised a practical issue: responsibility when things go wrong.
“Who is responsible for service-level breaches, and at what cost?” he asked. “How do I ‘fire’ a manufacturer when they have control over the maintenance of my infrastructure? Do I have to replace my infrastructure to get out of that relationship?”
These are not edge cases. They go to the heart of how enterprise IT is governed and how failure is managed.
Niel Nickolaisen, chairman of the CIO Council, FC Centripetal
A broader shift in control
The Colorado proposal may be one example, but it points to a wider trend. As digital infrastructure becomes more critical and more complex, the pressure to secure it will continue to grow. So, too, will the incentives for vendors to position themselves as the safest stewards of that infrastructure. The question is how far that logic extends.
The Colorado bill refers specifically to “critical infrastructure,” but this definition isn’t fixed. As more systems become essential to business operations, the scope of what qualifies can expand. If restrictions on repair grow alongside those definitions, the affect could reach far beyond the sectors initially targeted.
For CIOs, the challenge is not just responding to individual policies but also recognizing the underlying shift and taking steps to minimize its impact. The right-to-repair debate is less about repair than about control: Who has the authority to act, under what conditions, and with what constraints?
“I am skeptical of legislation that is sponsored and driven by technology manufacturers,” Nickolaisen said. “I have never seen any that turned out to benefit the customers. And I do mean never.”
