When Good Vendors Have Bad Years: Recognizing Systemic Security Failures Before They Become Your Problem

Why CISOs must evaluate vendors beyond CVE counts and start measuring engineering discipline, transparency, and operational resilience.

For years, security leaders have evaluated technology vendors using a familiar set of criteria: product capabilities, Gartner positioning, feature velocity, market share, integration complexity, and price. These are reasonable inputs. They reflect the legitimate business pressures that shape technology decisions. Yet some of the most consequential cybersecurity incidents of the last five years have exposed a significant blind spot in how many organizations select and manage strategic technology partners.

The question is not whether a vendor will have vulnerabilities. Every software organization does, and the security industry long ago abandoned the fiction that any product can be made perfectly secure. The more important question is whether those vulnerabilities represent isolated engineering mistakes, or symptoms of a deeper, systemic failure inside the organization. That distinction matters enormously in practice, because replacing a strategic firewall platform, identity provider, endpoint solution, collaboration suite, or network infrastructure is measured in years, not weeks. Once an organization has standardized on a platform, it has inherited not only its capabilities but also its engineering culture, security maturity, release discipline, and incident response processes. Those characteristics become organizational risk as much as vendor risk.

Systemic Failure Leaves a Pattern

Security professionals frequently evaluate vendors through the lens of individual CVEs, but isolated vulnerabilities rarely tell the complete story.

A more meaningful indicator is whether vulnerabilities begin to exhibit recurring characteristics across multiple product lines or management platforms. When attackers repeatedly discover privilege escalation flaws, authentication bypasses, or weaknesses in the management plane, the conversation shifts from software defects to engineering discipline.

Cisco’s Catalyst SD-WAN platform provides a timely and instructive example. Throughout 2026, the company has disclosed multiple actively exploited vulnerabilities affecting one of the most critical components of enterprise network infrastructure. The campaign began with CVE-2026-20127, a critical authentication bypass affecting the peering authentication mechanism for Catalyst SD-WAN controllers, which investigators at Google Mandiant determined had been exploited by a sophisticated threat actor, later identified as UAT-8616, since as early as 2023, well before the vulnerability was publicly disclosed. A related flaw, CVE-2026-20182, targeted the same vdaemon service component and was also actively exploited as a zero-day. Together, these authentication bypasses enabled adversaries to establish unauthorized peering connections to SD-WAN Manager devices and gain administrative-level access.

What followed illustrates the compounding nature of systemic security debt. In early 2026, Mandiant investigated attacks targeting SD-WAN infrastructure at a communications service provider, discovering that the threat actor had leveraged prior unauthorized access to then exploit CVE-2026-20245, a command injection vulnerability in the Cisco Catalyst SD-WAN Manager CLI stemming from insufficient validation of user-supplied input. By uploading a malicious CSV file through the tenant-upload feature, the attacker escalated from compromised administrative credentials to root-level control of the SD-WAN management plane and in observed cases, pushed unauthorized configuration changes to managed edge devices throughout the organization’s network. Throughout the campaign, the threat actor employed systematic anti-forensic techniques, deleting malicious files, reverting configuration changes, and executing cleanup scripts to limit defenders’ ability to assess the scope of compromise. CVE-2026-20245 has since been identified as the seventh actively exploited zero-day affecting Cisco’s SD-WAN platform during 2026 alone.

The pattern across this series authentication bypass, privilege escalation, and management-plane manipulation, all concentrated within overlapping components of the same product, suggests that the Catalyst SD-WAN platform has accumulated meaningful security debt in precisely the areas that handle inter-device trust and administrative input processing. Security researchers have noted that multiple disclosures in this series implicate the same underlying code regions, a concentration that warrants not only urgent patch management but a broader reassessment of SD-WAN trust architecture across the enterprise.

Cisco is not alone in facing this challenge. Ivanti presents an equally significant case study in what sustained engineering pressure looks like from the defender’s perspective. Beginning with the disclosure of CVE-2023-46805 and CVE-2024-21887 in January 2024, two zero-days affecting Ivanti Connect Secure and Policy Secure that had already been exploited by a China-nexus espionage group tracked as UNC5221, the company entered a prolonged period of repeated exploitation cycles across multiple product lines. Within a year, UNC5221 was back, exploiting CVE-2025-0282, a critical unauthenticated buffer overflow in Connect Secure that had been actively exploited since mid-December 2024 before Ivanti disclosed the vulnerability. By April 2025, the same group had exploited CVE-2025-22457, a vulnerability that Ivanti had initially assessed as a low-severity bug and patched without a security advisory in February, before determining it was actively being weaponized for remote code execution. As of mid-2025, CISA’s Known Exploited Vulnerabilities catalog contained 30 Ivanti defects accumulated over four years, with UNC5221 marking its fourth zero-day exploitation campaign against Ivanti products in less than three years. Each successive campaign deployed increasingly sophisticated tooling SPAWN, TRAILBLAZE, BRUSHFIRE specifically engineered for persistence and detection evasion on Ivanti appliances, suggesting that adversaries have made a sustained investment in developing deep expertise against this particular vendor’s codebase.

Microsoft experienced its own difficult period during 2021, when the fallout from the Exchange Server compromises attributed to Chinese state-sponsored operators who had exploited four zero-days before Microsoft could disclose or patch them combined with an unusually dense vulnerability cadence across other enterprise products. The scale and speed of that exploitation wave forced many organizations to confront a reality they had previously treated as theoretical: that even the world’s largest software company can experience engineering and response conditions where defenders cannot keep pace with attacker innovation.

Different vendors, different products, different engineering organizations yet the lesson is consistent. Systemic security problems develop patterns long before they generate headlines, and the patterns are often visible to anyone willing to look beyond the individual CVE.

The Right Question to Ask

When a major vendor announces another actively exploited zero-day, leadership discussions often become reactive. Executives ask whether the organization should replace the vendor. That question is understandable, but it is usually the wrong starting point and pursuing it prematurely can create more risk than it eliminates.

The more productive question is whether the vendor has demonstrated the engineering maturity required to recover. Every organization capable of shipping complex software at enterprise scale will eventually ship defects that are discovered and exploited before disclosure. What differentiates vendors undergoing a difficult cycle from those experiencing genuine systemic failure is what happens in the period that follows. Do vulnerabilities decline in frequency? Does the vendor introduce architectural improvements, not just patches? Does leadership invest in secure development programs and measure their outcomes? Does executive communication acknowledge root causes including engineering debt, architectural assumptions, and development practices rather than simply acknowledging each individual incident? Organizations that treat failure as a learning input tend to emerge from difficult periods with stronger engineering practices. Organizations that treat failure as a communications challenge tend to repeat it.

The Hidden Cost of Platform Migration

One of the more persistent misconceptions in enterprise security is that changing vendors automatically reduces risk. In practice, replacing a strategic technology platform frequently introduces new categories of operational risk that security teams underestimate or fail to plan for adequately.

Firewall platform migrations routinely span twelve to twenty-four months, during which two different security control architectures must be maintained simultaneously. Identity platform replacements affect every user in the organization and can disrupt authentication workflows across business applications, remote access infrastructure, and security tooling. Network infrastructure replacement touches nearly every operational system. Endpoint migrations consume significant security engineering resources over multi-year timescales. Throughout each of these transitions, security teams operate in a state of elevated operational complexity precisely the conditions in which gaps emerge and incidents become harder to contain.

There is also the matter of institutional knowledge. Security teams develop deep familiarity with the platforms they operate. Detection engineering is tuned. Incident response playbooks are mature. Escalation paths are understood. Compensating controls are in place. That accumulated operational maturity does not transfer automatically to a new platform. The initial months on any new system represent a period of heightened exposure that organizations frequently underweight in migration planning. Rather than asking whether a vendor has experienced security failures, CISOs should ask a more operationally grounded question: can the organization safely operate this platform while systematically reducing its exposure to the platform’s most significant architectural assumptions? That is an achievable objective. Replacing the platform entirely may not be.

Security Accountability Belongs in the Contract

One lesson that organizations continue to learn the hard way is that procurement teams negotiate pricing far more aggressively than they negotiate security accountability. That imbalance has direct operational consequences when a vendor enters a period of sustained vulnerability.

Every strategic technology agreement should anticipate the possibility of a significant security event, because the evidence of the last several years suggests that such events are not exceptional they are predictable features of long-term vendor relationships. Contracts should establish clear expectations before a crisis begins: security notification timelines, executive briefing obligations during active incidents, access to dedicated response resources, defined patch SLAs for critical vulnerabilities, root-cause analysis delivery, forensic guidance, temporary compensating controls, security engineering escalation paths, and customer advisory participation during major incidents.

Most vendors will discuss these commitments before contracts are signed. Considerably fewer are willing to negotiate them once a crisis is already underway and organizational leverage has evaporated. The procurement phase is the moment of greatest leverage, and it should be used to establish not just commercial terms but the security accountability framework that will govern the relationship when conditions become difficult. Security is not purchased only through technology it is also purchased through the contractual structures that define what vendors owe their customers when their engineering processes fall short.

Architectural Concentration as Operational Risk

Another pattern that emerges from sustained vendor crises is the risk created by architectural concentration. Many organizations have built environments in which a single vendor provides identity, email, endpoint management, collaboration, cloud infrastructure, and security tooling simultaneously. The operational simplicity of that model is real and meaningful. The risk it creates is equally real. When one vendor experiences a systemic engineering problem affecting multiple product lines simultaneously as both Microsoft and Ivanti have illustrated an organization whose security posture is deeply concentrated in that vendor faces a compound exposure that no single remediation action can quickly resolve.

Cyber resilience increasingly resembles portfolio management in this respect. Diversification is not an expression of distrust toward any particular vendor. It is the recognition that no single engineering organization regardless of its scale, resources, or stated security commitments should represent a single point of organizational failure. The organizations that managed the Ivanti crisis most effectively in 2024 and 2025 were generally those that had maintained alternative remote access infrastructure, implemented strong compensating controls around privileged access to affected appliances, and could make an independent risk decision about whether to take an appliance offline without immediately losing a critical business capability.

Evaluating Engineering Behavior, Not Marketing Positioning

Marketing investments are not reliable predictors of future security performance. Engineering behavior is. Security leaders should track a set of vendor indicators that extend beyond traditional product evaluations and procurement diligence.

The questions worth asking include whether vulnerability disclosures are becoming more frequent over time, whether attackers are consistently discovering flaws before security researchers or the vendor’s own teams, whether the vendor is repeatedly responding to nation-state exploitation rather than opportunistic campaigns, whether secure development initiatives produce measurable changes in vulnerability cadence, whether executive leadership communicates about root causes or exclusively about individual patches, whether recurring vulnerabilities implicate overlapping components across different product families, and whether post-incident transparency provides customers with the forensic guidance and architectural context needed to assess their own exposure. One difficult year is an engineering event. Two consecutive difficult years deserve executive attention. Three years of recurring exploitation within the same product domain warrants a governance-level review of the relationship and a formal assessment of long-term strategic direction.

Designing for Vendor Failure

Perhaps the most consequential lesson from the Cisco, Ivanti, and Microsoft experiences is architectural: vendor security should not become organizational security. Security programs that design for vendor failure not as a pessimistic contingency, but as a realistic operating assumption—develop fundamentally different capabilities than those that treat strategic vendors as reliable security controls.

The assumption of eventual vendor compromise changes architecture decisions. It changes how network segmentation is designed and enforced. It changes how privileged access to management planes is provisioned, monitored, and constrained. It changes how detection engineering is structured to identify anomalous activity on infrastructure platforms where vendor-provided telemetry may be limited or tampered with. It changes how incident response playbooks are constructed. The Mandiant investigation into the Cisco SD-WAN campaigns documented sophisticated anti-forensic tradecraft specifically designed to reduce defender visibility on network infrastructure. Organizations whose detection and response capabilities assume that management plane telemetry is trustworthy are poorly positioned to respond when that assumption is invalidated.

Organizations that architect for vendor compromise recover faster, because failure was already part of the design.

The AI Accelerant: Why No Vendor Will Be Immune

Everything discussed in this article—the recurring patterns in Cisco’s SD-WAN platform, UNC5221’s sustained campaign against Ivanti, the pace at which sophisticated adversaries discover and weaponize flaws before disclosure was produced in an environment where vulnerability discovery was still primarily a human endeavor. That environment is changing rapidly, and the implications for vendor risk management are significant.

In May 2026, Google’s Threat Intelligence Group published a disclosure that the security community had been anticipating with some anxiety: the first publicly confirmed case of a zero-day exploit developed with the assistance of a large language model. The vulnerability was a 2FA bypass in a widely used web administration tool, and GTIG assessed with high confidence that an AI model had been used to support both its discovery and weaponization. The exploit code bore the hallmarks of LLM-generated output structured Pythonic formatting, detailed docstrings, an educational style characteristic of model training data. The vulnerability itself was a high-level semantic logic flaw stemming from a hard-coded trust assumption, precisely the category of subtle, non-obvious defect that language models have demonstrated particular facility in identifying. As GTIG’s chief analyst John Hultquist stated in connection with the disclosure, the AI vulnerability race is no longer approaching, it has already begun, and for every AI-assisted exploit that becomes visible, there are likely many more that do not.

This development does not represent a discontinuous shift so much as an acceleration of existing dynamics. CrowdStrike’s 2026 Global Threat Report documented a 42% year-over-year increase in the number of zero-days exploited prior to public disclosure in 2025 alone. More than 48,000 new CVEs were published in 2025; industry analysis suggests that if AI accelerates vulnerability discovery by even a factor of ten, defenders could be managing a volume of known vulnerabilities in the coming years that makes today’s patch cadence look orderly by comparison. DARPA’s AI Cyber Challenge, which concluded in 2025, demonstrated that AI systems at the frontier of capability could identify 54 vulnerabilities across 54 million lines of code in approximately four hours of cloud compute time. Competition conditions differ from production environments, but the directional implication is clear: AI-assisted vulnerability research can operate at a speed and scale that human research cannot match, and that capability is becoming available to a broadening range of actors.

The specific impact on enterprise infrastructure vendors is worth examining carefully. The Cisco SD-WAN and Ivanti exploitation campaigns described earlier in this article were conducted by sophisticated, well-resourced nation-state actors who invested heavily in developing expertise against specific vendor codebases over extended periods. AI-assisted vulnerability discovery changes the economics of that investment. Identifying authentication bypass flaws, input validation weaknesses, and privilege escalation paths—the categories of defects that have repeatedly appeared in both the SD-WAN series and Ivanti campaigns is precisely the work that frontier AI models have shown measurable capability to perform. Palo Alto Networks, which tested frontier models as part of a structured research program, concluded that the latest models are extraordinarily capable at finding vulnerabilities and converting them into critical exploit paths in near-real-time. Broadcom’s own testing found that the interval between vulnerability discovery and functional exploit generation is compressing to the point where prioritization as a defense strategy begins to fail: by the time a security team has ranked an issue as low priority, an AI-assisted attacker may have already chained it with two other flaws into a working exploit.

This has a direct consequence for how organizations evaluate vendor security maturity. The relevant question is no longer simply whether a vendor has a secure development lifecycle, but whether that vendor’s engineering investment is positioned to operate at the speed the emerging environment demands. As one industry observer noted at RSAC 2026, every major software vendor should already be integrating frontier AI into security engineering end to end vulnerability discovery, exploit validation, patch generation, regression testing and vendors not doing this now will be behind within months. The organizations best positioned to manage this environment will be those that compete on remediation velocity: the speed from internal vulnerability identification to validated patch delivery, measured not in weeks but in days. Vendors that cannot demonstrate improving performance on that dimension represent a growing liability as AI capabilities diffuse more broadly.

The fundamental dynamic that makes this consequential for CISOs is asymmetric. AI-assisted attackers need to find one viable path. They can scan the attack surface continuously, at machine speed, without accountability for what breaks along the way. Defenders must secure every exposed system, validate every configuration change, and ensure that remediation does not disrupt business operations, a constraint that requires contextual understanding of interconnected systems that no model yet reliably provides. The gap between attacker and defender operational tempo, already visible in the Cisco and Ivanti campaigns, will widen as AI capability becomes more broadly available. Organizations whose vendor relationships are built on the assumption of a predictable, human-paced exploitation environment will find that assumption increasingly unreliable over the next several years.

The practical implication is that vendor risk management must now incorporate an additional dimension: not just whether a vendor manages vulnerabilities well today, but whether its engineering culture and investment posture are structured to remain competitive in an environment where the pace and scale of discovery will increase significantly and continuously. That is a harder assessment to make than reviewing a vendor’s CVE history, but it is the one that will matter most.

The CISO’s Take

The quiet shift happening across the industry is that vendor risk management is evolving from an annual governance exercise into an operational discipline. Questionnaires and procurement checklists remain necessary, but they are insufficient instruments for managing the kind of sustained, sophisticated exploitation campaigns that security leaders are now navigating and increasingly insufficient for the AI-accelerated environment taking shape around us.

The most effective CISOs are no longer evaluating vendors solely on today’s capabilities. They are evaluating how vendors behave on their worst day, and whether their engineering investment positions them to perform in an environment where their worst day will arrive more frequently and with less warning than it did even two years ago. That means negotiating security accountability into contracts before a crisis begins, maintaining architectural diversity sufficient to make independent risk decisions, implementing detection and response capabilities that do not depend entirely on vendor-provided telemetry, and designing compensating controls that remain effective when management infrastructure is potentially compromised.

The central insight is that enterprise technology eventually becomes too embedded to replace quickly. That is not a failure of planning, it is an inherent characteristic of strategic technology at scale. The leadership challenge is not to prevent that dependency from forming. It is to manage engineering risk within that dependency intelligently: with clear eyes about what strategic vendors owe their customers, what organizational capabilities must exist independently of any single vendor’s security posture, and whether the vendors who have earned your trust today are investing to remain worthy of it as the threat environment accelerates around them.

No vendor will be immune to what the next several years will bring. The ones that emerge as durable partners will be those that treat engineering discipline and remediation velocity as competitive differentials, not just talking points. Evaluating which vendors are genuinely building toward that standard, and holding them accountable to it contractually and operationally, is increasingly the core of the CISO role.

That is the difference between managing technology and managing cyber risk.

Stay cyber safe.