For the first time in the history of Verizon’s Data Breach Investigations Report, exploiting software vulnerabilities has overtaken stolen credentials as the leading initial access method.
Verizon’s 2026 DBIR, based on incidents in its 2025 reporting dataset, says vulnerability exploitation accounted for 31% of breaches. Ransomware appeared in 48%, while third-party involvement also reached 48%.
The question is no longer simply, “How do we stop phishing?” A serious defense has to assume that someone will eventually steal a credential, exploit a bug, compromise a vendor or persuade a user to approve something dangerous.
The real objective is harder: make that first compromise difficult to achieve, limit what it can reach, detect it quickly and make recovery possible even when the attacker gets further than expected.
Start With the Attack Path, Not the Security Tool
One of the easiest mistakes in cybersecurity is buying controls before understanding how an attacker could actually reach the data.
Imagine an internet-facing application with a vulnerability. The attacker exploits it, steals an application credential, discovers an overly permissive service account and reaches a database containing customer records. The firewall did its job. The endpoint security product did its job. The breach still happened.
That is why I prefer to map the full attack path:
- What is exposed to the internet?
- Which identities can access it?
- What privileges do those identities have?
- Where can a compromised system move next?
- What sensitive data can it reach?
- What would alert us if somebody started taking that data?
NIST’s Cybersecurity Framework 2.0 provides a useful structure around Govern, Identify, Protect, Detect, Respond and Recover. The important part is the lifecycle: prevention without detection and recovery leaves a large gap.
Reduce the Attack Surface Before You Harden It
You cannot properly protect systems you do not know exist.
Start with an inventory of domains, subdomains, IP addresses, APIs, VPN gateways, cloud resources, SaaS applications, databases, service accounts and internet-facing management interfaces. Then remove what does not need to be exposed.
This sounds basic. It is also where many security programs become fragile. An old VPN appliance, forgotten staging server or unmaintained application can sit outside the main security workflow while remaining completely reachable.
CISA recommends reducing unnecessary internet exposure, maintaining supported software, applying security updates and continuously assessing externally accessible assets. Its Known Exploited Vulnerabilities Catalog is also a useful input for prioritizing vulnerabilities that are already being exploited in the wild.
Patch for Exploitability, Not Just CVSS
A critical vulnerability is not automatically your highest practical risk. An exploitable flaw on an internet-facing identity appliance can be more urgent than a severe issue on an isolated development machine.
I would prioritize vulnerabilities using a combination of:
- Whether exploitation is already observed in the wild.
- Whether the affected system is internet-facing.
- The privileges available after exploitation.
- The sensitivity of the connected data.
- Whether a compensating control already exists.
Verizon’s 2026 DBIR and Mandiant’s M-Trends 2026 both underline the continuing importance of vulnerability exploitation. Mandiant reported exploits as the most common initial infection vector in 32% of the intrusions it investigated during 2025.
Make Identity Harder to Steal and Easier to Control
Passwords should not be the strongest thing protecting your most valuable systems.
NIST’s current SP 800-63B guidance distinguishes phishing-resistant authentication from ordinary one-time passwords. Manually entered OTPs are not considered phishing-resistant because an attacker can relay the code. WebAuthn, which underpins FIDO2 authentication, provides verifier-bound authentication designed to resist this type of phishing.
For privileged accounts, I would make phishing-resistant MFA the target rather than treating “MFA enabled” as a finished security milestone.
Then reduce privileges:
- Use separate administrative identities.
- Eliminate unnecessary standing administrator access.
- Prefer time-limited privilege elevation.
- Review dormant accounts and service accounts.
- Revoke sessions and tokens when credentials are compromised.
A password reset alone is not enough when an attacker may already possess an authenticated session.
Assume the Application Will Be Attacked
OWASP’s Top 10:2025 puts Broken Access Control at number one. That is particularly relevant to data breaches because authentication and authorization are different problems.
A user can be perfectly authenticated and still be allowed to access another customer’s invoice, profile or document because the server failed to enforce ownership.
Every sensitive API request should effectively answer four questions:
Who are you? What object are you requesting? Are you allowed to access it? Which fields and actions are permitted?
For teams building web applications, the OWASP Application Security Verification Standard provides a more detailed basis for testing these controls.
Do Not Ignore the Supply Chain
Your application is probably not entirely yours. It depends on frameworks, libraries, containers, build systems, plugins, CI/CD pipelines and external services.
OWASP’s 2025 edition elevates Software Supply Chain Failures into its top three risks. Good controls include dependency monitoring, SBOMs, secret scanning, protected repositories, signed artifacts and separation of duties in CI/CD.
A particularly dangerous design is letting one compromised developer identity move from source code to production without another control standing in the way.
Watch What Happens After Authentication
Mandiant reported a global median dwell time of 14 days across its 2025 investigations. That number is a reminder that prevention is only half the problem.
Good monitoring should detect behavior such as:
- A user suddenly downloading thousands of files.
- A service account accessing a database it has never touched.
- A new OAuth application requesting broad permissions.
- An administrator creating privileged access at an unusual time.
- A server sending an abnormal volume of data to an unfamiliar destination.
OWASP’s 2025 Top 10 also includes Security Logging and Alerting Failures. Logs that nobody monitors are evidence after the fact, not necessarily protection during an attack.
Design Backups for the Day Everything Goes Wrong
CISA recommends maintaining offline, encrypted backups and regularly testing their integrity and restoration. That second part is easy to underestimate.
A backup job saying “successful” does not prove the business can recover.
Run an actual restoration exercise. Rebuild a critical system. Recover a database. Test whether the people responsible for recovery still have access. Ideally, keep recovery infrastructure sufficiently isolated that compromising the production identity system does not automatically hand an attacker the keys to the backups.
A Practical 30-Day Breach-Prevention Plan
You do not need to implement everything simultaneously. Start with the controls that close the most dangerous paths.
- Inventory: identify every internet-facing asset and its owner.
- Exposure: remove unnecessary public services and management interfaces.
- Vulnerabilities: prioritize actively exploited flaws and verify remediation.
- Identity: enforce MFA, then move privileged users toward phishing-resistant authentication.
- Permissions: eliminate excessive administrator, cloud and OAuth privileges.
- Applications: test authorization and sensitive API endpoints.
- Telemetry: centralize identity, endpoint, cloud, network and application security logs.
- Recovery: restore critical data from backup and document what failed.
- Response: rehearse compromised-account and ransomware scenarios.
The Real Way to Outsmart Cybercriminals
Trying to predict every technique an attacker might use is a losing strategy. There will always be another exploit, another phishing kit, another compromised vendor and another way to abuse legitimate credentials.
A stronger strategy is to make the attack chain progressively less useful.
Reduce exposure. Strengthen identity. Enforce authorization. Minimize privilege. Segment systems. Monitor behavior. Restrict data movement. Protect recovery systems.
That is what good breach prevention looks like in practice. The goal is not to build a system an attacker can never penetrate. The goal is to build one where a single mistake does not automatically become access to everything.
