The Common Misunderstanding About Zero Trust Adoption: What Security Assessments Reveal

Entering 2026, news of cyberattacks targeting major companies shows no sign of letting up, both in Japan and overseas. Nichirei’s logistics system outage, Aflac’s large-scale personal data breach, and the email information leak at a KDDI affiliate are just a few examples of damage spreading across industries.

I should note that what security measures those companies had in place has not been disclosed, and this article will not address that point. What I want to take up here is not the story of the victimized companies, but a common misunderstanding I have seen repeatedly at security project sites.

Attacks Keep Increasing

As a premise, I want to establish the fact that the sheer volume of attacks itself is surging.

According to research by the security firm Check Point, as of April 2026 an average of 2,048 cyberattacks per week were confirmed per organization in Japan, a 73% increase compared to the same month the previous year. This is a level that significantly exceeds the global average growth rate.

Looking globally, 707 ransomware attacks were disclosed in April 2026, a 5% increase month-over-month and a 12% increase year-over-year. Regardless of company size, cyberattacks are no longer “a story of a few unlucky companies.”

Amid these circumstances, what many companies raise as a countermeasure is “Zero Trust.” However, I feel that there is a significant gap in understanding at the field level about what this word actually means.

When You Hear “We’ve Adopted Zero Trust” and Conduct an Assessment

I have participated in multiple security projects. In that context, many companies explain to us that “we have adopted Zero Trust.”

However, when I actually assess the contents, in most cases the evaluation is NG.

When I ask the clients for the reason, the same answer usually comes back: “We introduced Zero Trust-related tools, so we understood it as a completed countermeasure.”

This is a very significant misunderstanding.

Zero Trust Is a Concept, Not a Product

Zero Trust is not the name of a specific product or tool. It is a “way of thinking” about the overall security design that does not assume the internal network is safe, and verifies every access each time.

Introducing one tool does not mean that this way of thinking has been implemented across the entire organization. Yet in actual practice, the following states are very often called “Zero Trust countermeasures completed.”

• Satisfied with only deploying an MFA tool
• Introduced an ID management product, but the privilege design is the same as before
• Only a part of the network is segmented, and the rest is left untouched
• Monitoring tools were installed, but the operation from detection to isolation is not in place

These are all merely “parts” of the elements that make up Zero Trust. Installing a tool is the starting point, not the goal.

“In Progress” Is Fine. The Problem Is “Believing It’s Already Complete”

What I don’t want misunderstood here is that the fact that Zero Trust migration is still underway is by no means a bad thing.

Zero Trust is an initiative that spans a very wide range of areas, including an organization’s ID foundation, network design, privilege management, and monitoring framework. It is natural to proceed in stages, and if the recognition is “we are still halfway there,” that is a healthy state.

The problem is the reality that many companies believe “it’s already complete” even though they are only halfway.

This is something I have felt firsthand through assessments, and I believe it is by no means an exceptional case. A forecast by the overseas research firm Gartner also states that by the end of 2026, only 10% of large enterprises will have fully mature Zero Trust programs. Compared to less than 1% in 2023, this is significant progress, but conversely, it means that 90% of companies are still only halfway there.

In other words, the majority of companies that claim to have “introduced” Zero Trust are actually in an incomplete state — this seems to be close to the reality from a global perspective as well.

Why Does This Misunderstanding Occur?

There are several conceivable reasons behind the birth of this misunderstanding.

One is that when vendors sell products as “Zero Trust-compliant products,” they tend to give the impression that introducing the product itself is the goal. In reality, that product is only one of the multiple pillars that make up Zero Trust.

Another reason is that for management and IT departments, the act of “buying and installing a tool” easily becomes a visible proof of achievement. On the other hand, the steady work of reviewing privilege design and building cross-departmental operational rules is hard to see and tends to be postponed.

As a result, the fact that “we spent budget and introduced a tool” takes on a life of its own, and the label “countermeasures completed” is applied without the actual defensive power to match it.

Why “Allowing an Intrusion” Must Not Be the End of the Story

Looking at news about cyberattacks, “a vulnerability was exploited” is often reported as the cause. But the actual intrusion path is not limited to that. According to one statistic, as intrusion methods, stolen credentials account for about 22%, phishing about 16%, and supply chain or contractor-related compromises about 13%, with attacks that exploit software vulnerabilities themselves being only a part of the breakdown. Cases in which the basic cause of misconfiguration has led to large-scale damage also continue to occur.

In other words, an attacker’s entry point into an organization spans a wide range: vulnerabilities, stolen credentials, phishing emails, or contractor management lapses. Whatever the route, no matter how many countermeasures are in place, it is realistically impossible to reduce the entry point to absolute zero. That means “allowing an intrusion” itself does not directly indicate a failure on the defender’s side.

What should really be questioned comes next. Even if an intrusion was allowed through some initial foothold, did the damage stop there without spreading to other systems? This is where Zero Trust should play its intended role.

Zero Trust is not a mechanism that brings intrusions to zero. It is a way of thinking that assumes intrusion will occur and confines damage to the initial point of compromise through authentication, privileges, and network segmentation. If Zero Trust were functioning as its name suggests, then regardless of what the initial intrusion path was, the situation should not develop into one where entire business operations stop.

Conversely, the very fact that damage originating from a single entry point has expanded to the point of business suspension or large-scale information leakage indicates that somewhere in that organization, the “mechanism to stop things after intrusion” was not functioning. The state I have seen in assessment settings — “tools are in place but not functioning” — almost always has a gap in exactly this area. Even if authentication tools or ID management products have been introduced, if they are not built up to a level that actually prevents lateral movement, the moment an intrusion is allowed the damage spreads easily.

In other words, the explanation that “there was a vulnerability, so we were attacked” is only part of the cause. A more essential question — “why did so much damage spread from that single entry point?” — is where the answer to whether Zero Trust was truly functioning lies.

The Points You Should Actually Examine

To judge whether Zero Trust is actually functioning, you need to look at the following perspectives, not the presence or absence of tools.

• Is authentication verified continuously on each access, rather than once and done?
• Are privileges narrowed to the minimum necessary, with no excessive privileged accounts left unattended?
• Is the network finely segmented, designed so that if one endpoint is compromised it does not spread to others?
• Is the operation from detecting an anomaly to actually isolating it in place at a level that truly functions?
• Is the same level of thinking enforced across the entire organization, including subsidiaries and contractors?

If even one of these is missing, that point may have become a place where “tools exist but do not function.” For an attacker, such gaps are the most easily targeted entry points.

Conclusion: Ask Not “Have We Adopted It” but “Is It Functioning”

Zero Trust is not a project that ends with adoption. It is a long-term initiative to embed the concept of continuous verification everywhere in the organization.

If your company currently believes “we have already adopted Zero Trust,” it is worth stopping once and confirming whether that is truly a “way of thinking” that has taken root across the entire organization, or whether it only refers to a specific “tool.”

Being in progress is not a problem. Rather, whether you can correctly recognize that state is surely the true first step in countermeasures. You cannot reduce the intrusion entry point to zero, but whether you can stop the damage after an intrusion is allowed should be changeable through design and operation.