Cybersecurity Lessons from Recent Breaches

Between late 2023 and early 2025, we've seen a cascade of breaches that share uncomfortably familiar patterns. MGM Resorts shut down for days after a social engineering attack. Change Healthcare, a critical healthcare infrastructure provider, paid a $22 million ransom and exposed protected health information on a third of Americans. Okta, a company whose entire business is identity security, disclosed multiple breaches stemming from credential compromise. Snowflake customers lost data because of credential stuffing attacks against accounts without multi-factor authentication.

Each breach generated headlines, finger-pointing, and promises to do better. What most post-mortems miss is the pattern recognition that matters: these weren't novel attack chains or zero-day exploits. They were predictable failures in foundational controls, executed by attackers who understood that organizations still struggle with basics.

I've spent two decades implementing security programs in regulated environments—healthcare, defense contractors, federal systems—and the cybersecurity lessons from recent breaches aren't about exotic threats. They're about the gap between what we say matters and what we actually fund, staff, and enforce. That gap is where breaches happen.

The Social Engineering Attack Surface Keeps Working

MGM's September 2023 breach started with a phone call. Attackers impersonated an employee, called the help desk, and gained access to privileged credentials. The result: systems down for over a week, slot machines offline, hotel key cards not working, and estimated losses exceeding $100 million.

Caesars Entertainment faced a similar attack in the same month. They paid roughly $15 million to prevent data publication. Both incidents used a technique called vishing—voice phishing—combined with publicly available information from LinkedIn and corporate websites.

The pattern I see across organizations isn't that help desk staff are incompetent. It's that we've built identity verification processes optimized for speed and customer satisfaction, not security. In my experience working with federal contractors and healthcare organizations, verification procedures often rely on information that's publicly available or easily guessable: employee ID formats, manager names, department structures, recent company events.

What would have changed the outcome? Not security awareness training alone, though that matters. The control that would have mattered is technical enforcement: time-delayed privileged access elevation, callback verification from known numbers, mandatory out-of-band confirmation for credential resets on privileged accounts, and logging sophisticated enough to detect impossible travel or unusual access patterns within minutes, not days.

Most organizations I work with have some version of these controls documented in policy. Few have them technically enforced in a way that survives the pressure to "just reset the password quickly."

Supply Chain Risk Is No Longer Theoretical

The Change Healthcare breach in February 2024 was particularly damaging because of where it hit: a central node in healthcare claims processing. When Change Healthcare went down, pharmacies couldn't process prescriptions, healthcare providers couldn't submit claims, and patients couldn't get medications. The ransomware attack succeeded through a compromised credential on a Citrix remote access portal that didn't have multi-factor authentication enabled.

This wasn't a sophisticated supply chain attack like SolarWinds. It was a basic control failure at a company that processed sensitive data for thousands of healthcare organizations. The breach exposed that most covered entities under HIPAA have no realistic ability to ensure their business associates implement basic security controls, and even less ability to detect when those controls fail.

I've reviewed hundreds of Business Associate Agreements in healthcare contexts. Most contain strong language about security obligations. Almost none contain enforceable audit rights, real-time security monitoring requirements, or breach notification SLAs that would actually matter during an incident. Organizations sign these agreements, check a box on their HIPAA compliance checklist, and assume the risk is managed.

The cybersecurity lessons from recent breaches in the supply chain space are clear: your security program's perimeter is defined by your least secure critical vendor, and contract language doesn't stop ransomware. What would have changed the outcome at Change Healthcare? Technical controls: enforced MFA on all remote access without exception, network segmentation limiting the blast radius of a compromised credential, and privilege management that doesn't allow domain admin level access from internet-facing systems.

For organizations dependent on critical vendors, the control that matters is redundancy. If a single vendor outage can halt your operations, you don't have a vendor security problem—you have a business continuity problem that no amount of contract negotiation will solve.

Identity Systems Remain the Highest-Value Target

Okta disclosed multiple security incidents in 2023 and 2024, including unauthorized access to their support case management system and a breach of their source code repository. For a company whose product is identity and access management, these breaches were particularly damaging to trust. The root causes varied—compromised service accounts, insufficient access controls on support systems, credential theft from employee devices—but the pattern is consistent: attackers understand that identity infrastructure is the skeleton key to everything else.

Organizations have spent the last decade moving to cloud services and centralizing authentication through single sign-on systems. That architectural decision created enormous efficiency gains and also created single points of catastrophic failure. When your entire application portfolio trusts a single identity provider, compromise of that provider means game over.

The control gap isn't using identity providers—that ship has sailed, and for good reasons. The gap is in how we protect those identity systems themselves. In regulated environments I work with, I see organizations enforce MFA for end users but run service accounts without it, require password rotation for employees but not for privileged service principals, and monitor user behavior but not administrative actions within the identity provider itself.

What would have changed outcomes in identity-focused breaches? Defense in depth for the identity layer: privileged access workstations for identity administrators, phishing-resistant MFA methods like FIDO2 rather than SMS or push notifications, real-time monitoring of directory changes and privileged role assignments, and architectural isolation so that support systems can't directly access production identity infrastructure.

The MFA Reality Check

Multi-factor authentication prevents most credential-based attacks, but only if it's actually enforced and resistant to common bypass techniques. The Snowflake-related breaches in mid-2024 compromised numerous customer environments because accounts weren't protected by MFA. Attackers used credentials obtained from infostealer malware and credential dumps to access customer environments directly.

Snowflake's architecture allowed customers to enforce MFA but didn't require it. Organizations assumed their data was protected by default. It wasn't. This is a pattern I see constantly: security controls available but not enforced, optional security settings left to customer discretion, and shared responsibility models where the lines of responsibility aren't clear until after the breach.

For executives evaluating cloud platforms, the question isn't whether security features exist—it's whether insecure configurations are even possible. If your platform allows production data to be accessed without MFA, someone will eventually configure it that way. The control that matters is enforced baseline security that can't be turned off, not optional security features buried in settings.

Ransomware Operators Understand Your Recovery Plans Better Than You Do

Ransomware remains the most financially damaging category of breach. What's changed isn't the encryption—it's the business model. Modern ransomware groups now exfiltrate data before encrypting, operate access-as-a-service models for initial compromise, and have sophisticated negotiation teams who research their targets' financials, insurance policies, and regulatory obligations.

The attacks that succeed aren't hitting organizations with no backups. They're hitting organizations whose backups are accessible from the same credentials as production systems, whose recovery procedures haven't been tested under stress, whose backup retention doesn't account for the dwell time between initial compromise and ransomware deployment, and whose incident response plans assume cleaner networks than actually exist.

I've been brought into organizations post-breach where backups existed but were encrypted alongside production because they were mounted to the domain. I've seen recovery plans that assumed four hours to restore systems that actually took four weeks because the plans were written for isolated system failures, not adversarial destruction of infrastructure.

The cybersecurity lessons from recent breaches involving ransomware aren't about better antivirus. They're about resilience architecture: air-gapped or immutable backups that can't be deleted from compromised credentials, recovery procedures tested against adversarial scenarios not just technical failures, network segmentation that limits lateral movement, and privilege models that assume breach.

The Dwell Time Problem

Most ransomware attacks succeed after weeks or months of network presence. Attackers use that time to map your environment, identify your backups, locate your most critical systems, and position themselves for maximum damage. The organizations that recover quickly are those who detect the reconnaissance phase, not those who respond quickly to the ransomware deployment.

This requires monitoring focused on anomalous behavior rather than known malware signatures: unusual authentication patterns, privilege escalation attempts, access to backup systems from unexpected sources, large-scale data enumeration, and lateral movement using legitimate tools. Most organizations generate these logs but don't have the tooling or staffing to analyze them in real time.

Third-Party Risk Management Is Mostly Theater

The cybersecurity lessons from recent breaches consistently demonstrate that third-party risk questionnaires don't prevent third-party breaches. Organizations send detailed security assessments, vendors complete them, contracts include security requirements, and breaches happen anyway. The gap between attestation and reality is enormous.

I've reviewed third-party risk programs in healthcare, defense, and financial services. The common pattern is assessment theater: lengthy questionnaires that vendors fill out once during onboarding, annual attestations of compliance with security frameworks, and contract terms requiring notification of breaches. What's consistently missing is continuous validation, technical security monitoring, and enforceable consequences.

When Change Healthcare was breached, thousands of healthcare organizations discovered they had no visibility into the security posture of a vendor that processed their most sensitive data. When Okta was compromised, organizations using it for authentication had no independent ability to detect that compromise. When Snowflake customers were breached, there was no central notification because each incident affected different customer accounts.

The control that would change outcomes isn't better questionnaires—it's architectural isolation. Critical vendors should operate in network segments that limit what they can access if compromised, data shared with vendors should be minimized and monitored, vendor access should use separate credentials with conditional access controls, and vendor actions in your environment should be logged and alerted on.

For organizations in regulated industries, the harder truth is that some vendor relationships create risks that can't be fully mitigated. If a single vendor processes claims for your entire industry, you don't have a choice about using them, and you can't reduce the blast radius of their breach. That risk needs to be explicitly understood by leadership, disclosed to your board, and planned for in business continuity terms. A well-documented vendor assessment program doesn't change the fact that you're operationally dependent on someone else's security program.

For organizations choosing vendors, especially those in regulated environments working toward compliance frameworks like CMMC or HIPAA, this is where executive leadership's role in cybersecurity becomes critical. CEOs and boards need to understand that vendor selection is a strategic security decision, not just a procurement exercise.

The Controls That Actually Change Breach Outcomes

Looking across the breaches from the past 18 months, the same controls appear repeatedly as the ones that would have prevented or significantly limited damage. These aren't exotic or theoretical—they're foundational controls that organizations struggle to implement because of cost, complexity, or operational friction.

Enforced Phishing-Resistant MFA on All Access Paths

Not optional MFA. Not SMS-based MFA. Not push notification MFA that can be fatigued into approval. Enforced, phishing-resistant MFA using FIDO2 or certificate-based authentication on every access path to every system, with no exceptions for service accounts, no emergency backdoors, and no legacy systems exempted indefinitely.

The operational friction this creates is real. Legacy applications don't support modern authentication, vendors don't integrate with your identity provider, emergency access procedures take longer. But the pattern across recent breaches is clear: the organizations that fell to credential-based attacks were those where MFA had exceptions, workarounds, or implementation gaps.

Privileged Access Management That Assumes Breach

Privilege should be temporary, logged, monitored, and granted through separate credentials from daily use accounts. When administrative actions occur, they should require approval workflows, be limited to specific time windows, and be conducted from hardened privileged access workstations. Service accounts with privileged access should have credentials rotated automatically and usage patterns that trigger alerts when deviated from.

This is the control that would have prevented or detected most of the breaches in this analysis. In practice, it's one of the hardest to implement because it requires rearchitecting how administration works across your entire technology stack. Organizations I work with often have privileged access management as a roadmap item for years because the operational change management is complex.

Network Segmentation That Limits Lateral Movement

Flat networks are operationally convenient and a gift to attackers. Segmentation that enforces least-privilege network access means a compromised workstation can't reach backup systems, a breached vendor portal can't access internal business systems, and a ransomware infection in one environment can't propagate to others.

Modern cloud environments make this easier through security groups and identity-based access controls. Legacy on-premises networks make it harder because segmentation often requires physical network redesign. The organizations that recover from ransomware quickly are consistently those with effective segmentation limiting the blast radius.

Monitoring That Detects Reconnaissance, Not Just Exploitation

Most security monitoring focuses on detecting known malware or exploitation attempts. By the time ransomware deploys, attackers have been in your environment for weeks. The detection that matters is behavioral: unusual authentication patterns, privilege escalation, access to sensitive systems from unexpected sources, data enumeration, and lateral movement.

This requires baseline understanding of normal behavior, correlation across disparate log sources, and either significant security operations center staffing or investment in automation that can surface high-fidelity alerts. Most organizations have the logs but lack the analysis capability.

When working with organizations as a virtual CISO, this is often where I see the biggest gaps—not in collecting data, but in turning it into timely detection. For organizations considering external security leadership, understanding what good looks like in the first 90 days of a vCISO engagement includes establishing this detection capability as an early priority.

What Executives Should Actually Do With These Patterns

The cybersecurity lessons from recent breaches translate to resource allocation decisions and strategic questions that belong in the boardroom. The pattern across these breaches isn't that organizations lacked security programs—it's that they had programs built on policies and assessments rather than technical enforcement and resilience.

For executives, the questions worth asking aren't "did we complete our security training" or "did we get our SOC 2 report"—those are compliance artifacts. The questions that correlate with breach resistance are:

• Can any user access production systems without phishing-resistant MFA? If yes, when will that change and what's blocking it?
• If our most critical vendor suffered a breach today, what systems would be affected, and how long until we knew?
• When did we last test recovery from backups under the assumption that production and domain controllers were destroyed by an adversary?
• What percentage of our privileged access occurs through just-in-time elevation with approval workflows versus standing admin rights?
• How long does it take us to detect lateral movement or privilege escalation in our environment, and how do we know?

These aren't questions that security teams can answer with policy documents. They require technical validation, investment in controls, and operational processes that create friction. That friction is the point—security that's invisible is often security that's not enforced.

The strategic implication from recent breaches is that resilience matters more than prevention. You can't prevent all compromises—attackers will find a way in through social engineering, vendor relationships, or exploitation of complex systems. What separates contained incidents from catastrophic breaches is how quickly you detect, how effectively you contain, and how resilient your recovery capabilities are when containment fails.

Organizations that treat cybersecurity as a compliance program struggle with this because compliance is binary—you're compliant or you're not. Resilience is a spectrum, and it requires ongoing investment in detection capabilities, recovery testing, architectural isolation, and the operational maturity to maintain those controls under pressure.

For boards evaluating their organization's cybersecurity posture, the lesson from recent breaches isn't to demand more reports or frameworks. It's to understand whether the organization's security program is built on attestation or enforcement, whether recovery capabilities have been tested under adversarial scenarios, and whether critical dependencies on vendors create risks that no amount of contracting can eliminate.

The breaches from the past 18 months weren't sophisticated. They were successful. The gap between those two facts is where leadership attention and resources need to focus.