Opinion: Defense-in-Depth Comes From Coverage, Not a Longer Vendor List

Defense-in-depth might be the most repeated phrase in cybersecurity, and one of the least understood. Almost every security program claims to have it. Few teams have actually stopped to ask what it’s supposed to mean in practice, or whether the version they’ve built still matches the original idea.

The gap between the phrase and the practice matters more now than it used to, because the decisions that build or erode a layered defense are rarely made all at once. They show up as a leaner budget this year, a short-staffed quarter, or one more vendor renewal signed under deadline pressure because there wasn't time to evaluate an alternative. Each of those decisions feels minor on its own, but together, they quietly determine whether an organization's defense is actually layered or just looks that way on paper.

Defense-in-depth became a synonym for vendor count

Ask most IT teams what defense-in-depth means in practice and the answer tends to be a list: a firewall vendor, an EDR vendor, an email security vendor, an identity vendor, and if there’s budget left over, a separate vendor for Security Awareness Training (SAT) and phishing simulations. Each addition made sense in isolation. Together, they turned a design principle into a purchasing habit, where depth gets measured by how many line items show up on a renewal schedule rather than by what those tools actually cover together.

For lean, resource-constrained IT teams, that habit carries a cost separate from the price of the licenses themselves. Every additional vendor brings its own console, alert logic, and maintenance calendar. A five-person team running seven or eight disconnected systems spends a meaningful share of its week keeping the stack running by reviewing alerts that don’t share context, renewing licenses, and troubleshooting integrations that were never designed to talk to one another. That work absorbs hours that could otherwise go toward reducing risk, and it forces teams to prioritize keeping tools running over improving what those tools protect.

The threat model is moving faster than staffing

Small security teams are becoming more common as budgets tighten, and team fatigue sets in. At the same time, the barrier to a convincing social engineering attempt keeps dropping. AI is as available to attackers as it is to defenders, and a threat actor with even modest resources can now research a target, mimic a familiar tone, and launch a targeted phishing attempt in a fraction of the time it used to take. Finding the one person in an organization who will click, answer, or approve something they shouldn’t is no longer as resource-intensive as it once was.

Credential abuse and phishing are also compounded by the rapid, often unsanctioned adoption of third-party AI tools across the workforce, which means visibility can no longer stop at the endpoint. It has to extend to logins, file access, SaaS applications, and how employees are using AI tools day to day. Any threat model built before this shift needs to account for this expanded attack surface.

The layer closest to the attacker is usually the one that gets cut first

SAT and phishing simulations rarely generate their own alerts. Nothing escalates automatically when a training cycle gets skipped for a quarter. A missed patch or an exposed port eventually shows up on a scan. When a lean team runs out of hours, the layer without an alarm attached often gets pushed to next quarter, then the quarter after that. It happens one deprioritization at a time and rarely gets revisited until something forces the issue.

Recently, a threat cluster tracked as UNC6671 has been linked to a wave of attacks against financial services, private equity, and professional services firms, including organizations with comparatively mature security programs. Attackers pose as IT help desk personnel and contact employees directly on their personal mobile phones, claiming an urgent security migration requires immediate action. Victims are directed to a spoofed login portal where infrastructure positioned between the victim and the real service intercepts both credentials and multi-factor authentication tokens in real time. From there, the stolen access can enable attackers to move across an organization's connected SaaS applications, including platforms like Microsoft 365 and Okta, without compromising each one individually.

If organizations with dedicated security teams and mature awareness programs are still working through incidents like this, leaner IT teams should take notice. One of the most important defenses against a fabricated call from a fake help desk is training people to recognize it, and that layer is exactly the one most likely to be underfunded in a stack built through accumulation rather than design.

Depth without sprawl comes from consolidation

One response taking shape across the industry is the idea of a workspace cybersecurity platform: a single system built to protect everything an employee touches at work - from laptops and logins to applications, files, and increasingly AI tools - instead of stitching together a separate product for each one. For resource-constrained IT teams, that model directly addresses the operational problem vendor sprawl created in the first place.

Consolidating visibility and response into one system means fewer consoles to check, fewer integrations to maintain, and more shared context across security functions. Instead of forcing teams to piece together activity across disconnected tools, a unified platform can make it easier to recognize when seemingly separate events are part of the same attack. It also gives a layer like SAT a better chance of getting the same attention as the technical ones, instead of losing out to whichever tool has the loudest alert.

Consolidating the core stack this way also gives a small IT team back administrative hours that used to go into managing seven or eight separate vendor relationships. Those hours can go toward strengthening the rest of the environment, which is what turns a checklist version of defense-in-depth into a defense that works as a system.

What real depth requires

People will always be a target, and no policy changes that. What changes is whether SAT gets treated as a core part of the stack or as the piece that gets sacrificed when time runs short. That distinction is what separates organizations that only look prepared from those that have built meaningful layers of protection, and it shows up most clearly in how SAT gets built.

When SAT operates as part of a unified platform rather than a standalone project, a lean team can build broader layered coverage without adding another standalone console or management burden. The recent UNC6671 attacks reinforce why the human layer belongs in that strategy. Attackers impersonating a help desk over the phone are betting that no one prepared an employee for that exact moment, and that bet becomes easier when employee awareness is treated as secondary to technical controls.

A security program earns the label defense-in-depth when every layer, including the one built around people, holds up under pressure, regardless of how many vendors sit behind it.

Vincent Delbar is Director of Sales Engineering at Coro Cybersecurity. The views expressed in this article are those of the author and do not necessarily reflect the views of Security Guys News.