The Conventional Wisdom
Every TPRM team knows the script: legacy systems are inherently risky. When you acquire a company, you're supposed to inventory their technical debt, flag the old platforms, and prioritize migration to modern infrastructure. The Oracle-Cerner breach affecting 20 million people seems to prove this point. Legacy Cerner servers that hadn't been migrated to Oracle Cloud were compromised using stolen credentials. The breach started in January 2025, went undetected until February, and Oracle acquired Cerner in 2022. Three years to migrate critical health record systems, and they still got breached on the old stack.
The takeaway everyone's repeating: legacy systems are ticking time bombs. Get them off your books fast.
Why We Disagree
Here's what that narrative misses: the Oracle breach didn't happen because Cerner's servers were old. It happened because Oracle ran a three-year integration window without implementing compensating controls for systems they knew were vulnerable and hadn't yet migrated.
Think about your own M&A due diligence workflow. You're assessing the target's security posture, cataloging their critical systems, and building a post-close integration roadmap. But what happens on day one after the deal closes? The acquired entity's systems don't vanish. They're still processing data, still exposed to the same threats, and now they're your liability.
The real risk isn't the legacy technology itself. It's the governance gap that opens when you own systems you haven't yet secured. Oracle knew these servers existed. They knew they contained protected health information for millions of patients. They knew migration would take years. What they apparently didn't do was treat those servers as if they were already part of the Oracle production environment.
The Evidence
Look at the timeline. Oracle closed the Cerner acquisition in 2022. The breach began in January 2025 and wasn't detected until February 2025. That's a three-year window where these systems were Oracle's responsibility but apparently not receiving Oracle-grade monitoring.
The attack vector tells you everything: stolen credentials. Not a zero-day exploit, not a sophisticated supply chain compromise. Someone used valid login credentials to access servers that should have been under heightened scrutiny. The breach went undetected for weeks, suggesting that continuous monitoring wasn't configured to Oracle's own standards.
Compare this to Oracle's other 2025 incidents. The March breach exploited a vulnerability in Oracle Cloud's Single Sign-On. The September Clop ransomware campaign hit a zero-day in Oracle's E-Business Suite. Those are different failure modes. The Cerner breach is a monitoring and access control failure during a known integration period.
Multiple healthcare systems issued breach notices throughout 2025. Mosaic Life Care reported nearly 145,300 affected patients in June 2025. ChristianaCare, LifeBridge Health, and others followed. These weren't sudden discoveries. This was a rolling acknowledgment that Oracle was still figuring out what had been compromised months after detection.
What to Do Instead
If you're conducting due diligence on an acquisition target, or if you're a vendor analyst evaluating a provider that's recently acquired another company, shift your focus from "how old are their systems" to "how are they governing systems during integration."
Build a Day-One Security Baseline
Before the deal closes, inventory every system that will remain operational post-acquisition. For each one, document:
- What data it processes and where it's classified under your risk taxonomy
- Current access controls and whether they meet your identity governance standards
- Existing monitoring coverage and alert thresholds
- Patch management cadence and whether it aligns with your vulnerability SLAs
If the target's systems don't meet your standards, you've got two options: accelerate migration or implement compensating controls immediately. There's no third option where you own the risk but defer the work.
Treat Integration Period as Elevated Risk
Your criticality classification framework should flag any system in active integration as automatically elevated. This isn't about the technology's age. It's about the operational reality that you're managing infrastructure you don't yet fully understand, with staff who may not yet follow your procedures, under monitoring tools that may not yet be integrated with your SOC.
That elevated classification should trigger:
- Enhanced logging and real-time alerting, not batch reviews
- Accelerated access reviews (monthly, not quarterly)
- Dedicated incident response runbooks that account for unfamiliar system architectures
- Executive-level reporting on integration security milestones, not just migration timelines
Audit Your Vendors' M&A Activity
If you're evaluating a critical vendor that's recently acquired another company, your continuous monitoring should include:
- Requests for updated system inventories that distinguish between legacy and integrated infrastructure
- Specific questions about monitoring coverage for systems pending migration
- Breach notification timelines that account for detection delays in newly acquired environments
- Evidence that the vendor's security organization has operational control over acquired systems, not just contractual responsibility
This is where your Right to Audit becomes practical. You're not auditing whether they've migrated everything. You're auditing whether they've secured everything they own.
When the Conventional Wisdom Is Right
Legacy systems do carry inherent risk. Older platforms often lack modern security features like multi-factor authentication enforcement, behavior-based anomaly detection, or granular access logging. Vendor support windows expire. Patching becomes difficult or impossible. Technical debt accumulates.
If you're evaluating a vendor running critical workloads on genuinely unsupported infrastructure with no migration plan, that's a red flag. If they've been promising cloud migration for three years with no measurable progress, that's a substitutability concern.
But the Oracle-Cerner breach isn't a story about unsupported technology. It's a story about a three-year integration window where compensating controls apparently weren't sufficient to prevent or quickly detect a credential-based intrusion. The servers were legacy, but they were also actively managed by a major technology vendor with substantial security resources.
Your due diligence should distinguish between "we're running old systems with no plan" and "we're running old systems under heightened controls during a planned migration." One is unacceptable. The other is manageable if the controls are real.
The lesson isn't to avoid vendors with legacy infrastructure. It's to verify that any vendor managing systems they haven't yet modernized is treating those systems as if they're already under their security architecture. Because legally and operationally, they are.
