When “approved” becomes the attack surface.

For years, security programs have been optimized around a familiar question: What should we block? Malware, unknown executables, untrusted devices, suspicious network traffic, dangerous websites. That thinking remains necessary — but it is no longer sufficient.

Many of the most interesting attack paths begin on the other side of that boundary. They use software that is already installed, identities that already exist, permissions that were granted for legitimate reasons and workflows that employees rely on every day.

In other words: the attack may not begin where policy fails. It may begin where policy says yes.

“Approved” is a decision, not a guarantee

We naturally attach meaning to words such as approved, trusted, managed and authorized. They sound like end states. Once an application is approved or an identity has the right role, the security discussion can feel finished.

But approval usually answers only a narrow question: Is this thing allowed to exist or operate in this context? It does not answer what the application can be made to do, which resources an identity can reach, how two legitimate capabilities can be combined or whether a trusted workflow can be repurposed.

The question is no longer only: “What have we forbidden?” It is also: “What do we allow — and can we still control what that enables?”

The attack surface is increasingly made of legitimate capability

An attacker who can operate through familiar tools often gains an important advantage: less friction. A signed binary, an existing administrative tool, a permitted scripting environment or a valid user session does not look like an obvious violation. It looks like normal work — at least initially.

This changes the security problem. The challenge is not simply to identify bad objects. It is to understand capability, context and combinations.

From binary trust to controlled trust

The alternative is not to distrust everything. That would make modern organizations unusable. The more useful goal is controlled trust: allow legitimate work, but keep the resulting capability narrow enough to understand and govern.

That means moving beyond a binary allow/deny model and asking more precise questions:

• Scope: What exactly is being allowed — the application, a function, a user, a device, a location or a combination of these?
• Context: Does the same action make sense for this identity, on this endpoint, at this moment?
• Privilege: Is elevated access permanent, or can it be granted only when it is actually needed?
• Observation: Can we see what trusted components do after they are permitted?
• Revocation: Can trust be reduced or withdrawn quickly when context changes?

These questions are less comfortable than maintaining a blacklist or an allowlist because they force security to deal with real operational behavior. But that is precisely where modern control becomes valuable.

Good security creates useful friction — in the right place

Security teams are often asked to remove friction. The intention is understandable: nobody wants controls that make ordinary work unnecessarily difficult. But the answer cannot be zero friction everywhere.

The better objective is to put friction where risk increases. A standard user opening a known business application should not face the same controls as a process launching an unusual child process, an identity requesting elevated rights or a device attempting to move sensitive data outside its normal context.

This is where prevention becomes more granular. Rather than trusting a broad category forever, the organization keeps asking whether the next action still fits the reason trust was granted in the first place.

The strategic shift

The most important change is conceptual. Security architecture has traditionally been very good at separating known bad from allowed good. But as legitimate tools become part of attack chains, the line between those categories becomes less useful on its own.

Organizations therefore need to treat trust as something dynamic. Applications, identities, devices and data should not simply become trusted and disappear from view. Their permissions should remain understandable, observable and proportionate to the task.

That is a more demanding model — but also a more realistic one. Because the next significant attack may not announce itself by breaking a rule. It may begin by using exactly what the organization already approved.