Blog

I have nothing against audits. I have nothing against pen tests. They still matter.

But if you treat them as proof you are safe, you are going to learn the hard way that compliance is not the same thing as resilience.

I have seen too many organizations get hit right after “passing.” Then they’re sitting in a conference room staring at a report that looks clean, while their reality is on fire.

Here’s why that happens.

Scope is the first lie

The biggest weakness in most security programs is not technology. It’s scope.

Pen tests are scoped.
Audits are scoped.
Assessments are scoped.

And the modern breach often lives outside that scope.

It lives in identity.
It lives in SaaS.
It lives in delegated trust.
It lives in app-to-app integrations.
It lives in the places nobody “thought to include” because the organization is still thinking like it’s 2012.

So the report looks good. It’s not because the business is safe. It’s because the business was not fully evaluated.

Breaches don’t respect your control categories

Attackers don’t care how you labeled the work.

They don’t say, “This is an IAM issue, so I won’t touch it during the network test.”
They don’t say, “OAuth tokens aren’t in scope, so I’ll stop here.”

They take the easiest path to the highest value.

That path is frequently identity and trust.

A malicious app consented by a user.
A refresh token stolen and replayed.
A vendor integration abused.
A service account with long-lived privilege.
A mailbox rule created quietly.
A file share accessed legitimately, then exfiltrated.

These are breach mechanics that don’t show up in traditional reporting unless you explicitly hunt them.

The report problem

Most reports are written to prove something was checked.

What leadership actually needs is proof that the organization can withstand compromise.

That requires a different set of questions:

• Can we identify abnormal access patterns in SaaS quickly?

• Can we trace an identity’s reach across systems?

• Can we detect token misuse?

• Can we revoke access fast, without waiting on three vendors and a ticket queue?

• Can we tell what data was accessed, by whom, and when?

If those answers are vague, you are operating on hope.

What a modern review should include

If you want assessments that match how breaches happen now, you need to expand the lens:

1. Identity path mapping
   What can a compromised user reach? What can a compromised vendor reach?

2. OAuth and app consent review
   Which apps have access to mail, files, calendars, chat, directories?

3. Non-human identity governance
   Service accounts, API keys, automation identities. These are quiet kingmakers.

4. SaaS logging and investigation readiness
   Logs need to exist. They need to be retained. They need to be usable.

5. Containment drills
   Not tabletop theater. Real actions. Revoke tokens. Disable apps. Rotate keys. Validate blast radius.

This is the difference between a report you file and a program you can trust.

Closing

I’m not saying stop auditing. I’m saying stop worshipping it.

A clean report does not mean clean reality. It means the parts you looked at were clean, or at least looked clean from the angle you chose.

In Part 3, I’ll talk about what happens when we add agentic AI to this already messy trust landscape, and why AI is going to force every organization to get serious about identity ownership, reach, and revocation.

If you want to modernize your assessment approach, Critical Path Security can help you expand scope into the places that actually matter now.