In October 2026, on the thirty-second floor of a glass tower in Tokyo, thirty-nine-year-old cybersecurity strategist Naoki Shiraishi stared at a red dot blinking on a digital map of his company’s global network.
The dot represented a server in Singapore. A second appeared in Frankfurt. Then a third in Virginia.
For eleven months, Shiraishi had been responsible for defending Kensei Systems, a Japanese technology company supplying logistics software to manufacturers, shipping companies, and regional energy operators. Its systems coordinated warehouse robots, tracked international shipments, and processed operational data that customers could not afford to lose.
The company had invested heavily in cybersecurity. It maintained redundant servers, encrypted sensitive information, required multifactor authentication, and employed a security operations center that monitored suspicious activity around the clock. Its engineers conducted penetration tests, its employees attended security training, and its executives received quarterly reports showing that the company’s risk indicators were improving.
On paper, Kensei was well protected.
Yet the red dots on Shiraishi’s screen told a different story.
Someone had begun probing the company’s defenses from multiple locations. Some attempts were crude, easily blocked by automated filters. Others were more sophisticated, carefully spaced to resemble ordinary business traffic.
The security team had already blocked thousands of suspicious requests that morning.
Shiraishi watched the activity for several minutes before asking the question that changed the investigation.
“How many ways do we think an attacker could get into our network?”
The head of security operations, Emi Fujimoto, answered immediately.
“Thousands, potentially. Compromised credentials, vulnerable software, malicious attachments, exposed remote-access services, cloud misconfigurations, supply-chain attacks. We have controls for all of them.”
Shiraishi turned away from the screen.
“That wasn’t my question. How many ways have we actually considered?”
Nobody spoke.
He walked to the whiteboard and drew a circle representing Kensei’s network. Around it, he wrote the names of the company’s major defenses: firewalls, endpoint detection, identity management, backup systems, employee training, vendor assessments, and incident response.
Then he drew arrows pointing toward the circle from every direction.
“Think about what we’re doing,” he said. “We’re trying to protect every entrance, every employee, every device, every supplier, every cloud service, every forgotten account. We have to be right everywhere, all the time.”
He drew a single arrow pointing toward one small gap in the circle.
“The attacker only has to be right once.”
Fujimoto folded her arms. “And you’re suggesting we stop trying to defend everything?”
“No. I’m suggesting we stop thinking like defenders.”
That afternoon, Shiraishi requested permission to run an unusual exercise. Rather than commissioning another conventional penetration test, he wanted the security team to conduct an adversary-emulation exercise: a controlled simulation in which specialists would think and behave like a real intruder, following the same objectives an attacker might pursue.
The company’s executives hesitated. They had already paid consultants to test their defenses. What more could another exercise reveal?
Shiraishi presented them with two reports.
The first listed everything Kensei had successfully defended against during the previous year: blocked malware, rejected login attempts, patched vulnerabilities, and suspicious network connections terminated before they caused damage.
The second contained a single question:
If you were trying to cripple Kensei Systems without being detected, what would you attack first?
The executives approved the exercise.
The attacker’s perspective
Shiraishi assembled a small team consisting of an incident-response specialist, a cloud engineer, a software developer, and a former penetration tester named Ryoichi Matsuda.
Matsuda had spent years evaluating corporate security systems. He understood that organizations often measured their security by the strength of individual components: how sophisticated their firewall was, how many endpoints their monitoring software covered, and how quickly their engineers applied patches.
Attackers, however, rarely cared about these metrics in isolation.
They cared about the relationship between components.
A company might have excellent authentication controls but grant excessive permissions to a service account. It might encrypt its databases but allow an overly privileged employee to download their contents. It might meticulously secure its own servers while trusting a third-party software update without sufficient verification.
The weakness was often not a single broken lock. It was the assumption that every lock, keyholder, and trusted intermediary behaved as intended.
This was increasingly relevant in the cybersecurity environment of 2026. Industry incident-response research had highlighted the importance of compromised identities, stolen authentication tokens, and trusted software integrations. Artificial intelligence was also helping some attackers accelerate reconnaissance and social engineering, while creating new risks in enterprise applications and automated workflows.
Matsuda explained the principle to the team.
“Imagine we’re protecting a castle,” he said. “We reinforce the gates, build higher walls, station guards on the towers, and patrol the perimeter. But the enemy doesn’t necessarily need to storm the castle. Perhaps a merchant already has permission to enter. Perhaps a guard can open a door. Perhaps the castle’s own supply wagon carries something dangerous inside.”
He paused.
“The defender sees dozens of possible threats. The attacker sees a single route to the objective.”
The team began by mapping Kensei’s critical business processes rather than merely cataloguing its technical assets.
They identified which systems coordinated warehouse operations, which accounts could alter production configurations, which third-party services had access to internal data, and which dependencies would become critical during a disruption.
They also asked a more uncomfortable question: what would Kensei’s adversary actually want?
A criminal group seeking ransom would behave differently from a competitor seeking confidential information. A politically motivated actor might prefer a public disruption. An espionage operation might avoid causing damage altogether, because remaining undetected would be more valuable than making a dramatic entrance.
The same defensive weakness could therefore have radically different consequences depending on the attacker’s objective.
Shiraishi realized that his team had been designing defenses around the systems they owned, rather than the outcomes an adversary might seek.
That distinction changed their priorities.
The weakness nobody owned
Three days into the exercise, Matsuda identified an overlooked dependency in Kensei’s software distribution process.
The company relied on several external vendors for development tools, monitoring services, and cloud integrations. Each vendor had passed a security review. Contracts included confidentiality obligations, and the most important suppliers were required to report security incidents.
Yet the team discovered that responsibility for reviewing certain automated permissions was divided among three departments. The development team assumed the cloud team managed them. The cloud team assumed the vendor-management team had verified them. The vendor-management team believed the development team had already restricted access.
Each department had fulfilled what it believed to be its responsibility.
Collectively, they had left a gap.
Matsuda did not need to demonstrate a dramatic technical exploit. The exercise showed that a trusted connection could potentially have more access than its business purpose required, while no single team had a complete picture of that access.
The finding echoed a broader pattern in modern supply-chain security: an organization can inherit risk through software dependencies, compromised maintainer accounts, automated build systems, and trusted integrations. A perimeter can be technically strong while the relationships crossing it remain insufficiently controlled.
Fujimoto stared at the report.
“We spent millions protecting our infrastructure,” she said. “And the problem is that we trusted the wrong connection?”
“Not exactly,” Shiraishi replied. “We trusted connections without continually verifying what they were allowed to do.”
The distinction mattered.
A strategy based on eliminating all trust would make ordinary business impossible. Kensei could not operate without suppliers, customers, cloud services, and employees. The realistic objective was to limit the consequences when a trusted relationship failed.
The team therefore recommended several changes.
First, permissions would be restricted according to the principle of least privilege: each account and service should have only the access necessary for its assigned function.
Second, critical systems would be segmented so that a compromise in one area would not automatically provide access to everything else.
Third, privileged accounts and external integrations would undergo regular reviews, with unusual activity monitored continuously.
Fourth, the company would test its recovery arrangements, including isolated backups and the ability to continue essential operations when important systems were unavailable.
Finally, incident-response exercises would include scenarios involving suppliers, stolen credentials, and compromised internal accounts—not just malware arriving from outside.
These measures reflected the practical logic of zero-trust architecture. Rather than assuming that a user or device was safe because it was already inside the network, access would be evaluated according to identity, context, permissions, and the sensitivity of the requested resource.
But Shiraishi insisted that the technical changes were only half the solution.
The other half was learning to think like someone who did not share the company’s assumptions.
The defender becomes the strategist
Two weeks later, Kensei conducted a second exercise.
This time, the security team was divided into two groups. One defended the company’s logistics platform. The other acted as a simulated adversary, with a clearly defined objective: disrupt a critical service for as long as possible without triggering an immediate, coordinated response.
The exercise was conducted in a controlled environment, using synthetic data and isolated systems.
At first, the defenders concentrated on protecting the platform’s central servers. They strengthened access controls, watched network traffic, and prepared to isolate suspicious devices.
The adversary team, meanwhile, considered the company’s operational dependencies.
Which processes were indispensable? Which failures would force employees to stop working? Which safeguards might themselves become obstacles to recovery? What would happen if a service remained technically operational but could no longer receive reliable information from an upstream system?
The adversary team did not need to defeat every defense. It needed to identify the one failure that would have the greatest effect on the business.
During the exercise, the defenders detected and contained the simulated intrusion. Yet the disruption lasted longer than expected because the response team had focused on restoring the affected technology without first establishing which business functions had to be restored in what order.
The system was recovering.
The business was not.
Afterward, the two teams reconstructed the incident together. The defenders explained what they had seen; the adversary team explained which assumptions it had exploited. Each side learned how the other had interpreted the same environment.
Shiraishi watched the discussion with satisfaction.
The objective was not to prove that attackers were smarter than defenders. Nor was it to suggest that defense was futile.
It was to expose the asymmetry built into their respective tasks.
An attacker could choose the time, objective, and point of pressure. A defender had to maintain security across an interconnected environment, often without knowing which asset would be targeted or which warning would matter most.
The defender’s disadvantage was real, but it was not absolute.
The company could reduce its exposure by identifying its most consequential dependencies, limiting the reach of compromised accounts, improving visibility, and rehearsing recovery before an emergency. It could also force an adversary to confront multiple independent obstacles rather than relying on a single perimeter.
The purpose was not to make every possible attack impossible.
It was to make the most damaging attacks harder to execute, easier to detect, and less costly when prevention failed.
The final question
At the end of the month, Shiraishi presented his findings to Kensei’s board of directors.
One director asked whether the company would ever reach a point at which it could consider itself secure.
Shiraishi looked at the polished conference table, where the directors’ tablets displayed the revised risk dashboard.
“No organization can guarantee that every vulnerability has been eliminated,” he said. “Our environment changes whenever we hire someone, adopt a new service, update software, or connect another supplier. Security is not a condition we achieve once. It’s a capability we maintain.”
The director frowned. “Then how do we know whether we’re winning?”
Shiraishi replaced the dashboard with a simpler diagram.
It showed three concentric circles: prevent compromise, contain the impact, recover essential operations.
“We measure whether an attacker can get in, what they can reach if they do, and how quickly we can restore what matters. We also ask whether we’re making the same assumptions an attacker would exploit.”
He pointed to the narrow space between the circles.
“That is where strategy lives.”
As the meeting ended, Shiraishi returned to his office. The digital map still showed connections spanning Singapore, Frankfurt, Virginia, and Tokyo. New alerts appeared among familiar patterns of legitimate activity.
The network had not become simpler. The threats had not disappeared. And no amount of confidence could eliminate uncertainty.
But the company was no longer treating defense as an endless exercise in covering every conceivable opening with equal force.
It was learning to distinguish between what merely looked vulnerable and what an intelligent adversary would find valuable.
Outside, the city continued its ordinary rhythm. Trains arrived and departed. Warehouses processed shipments. Thousands of interconnected systems performed their work without attracting anyone’s attention.
Shiraishi understood that the strongest strategy was not simply to anticipate every move an opponent might make. That was impossible.
It was to understand the opponent’s incentives well enough to recognize which moves mattered most—and to build a system that could survive even when the opponent found an opening.
Because the defender’s task is to protect the whole, while the attacker’s task is to discover the part that can bring the whole down. The strategic advantage belongs to whoever understands that difference first.
All names of people and organizations appearing in this story are pseudonyms
Comments