Email to schedule an appointment: contactus@abatis.ch
AI is accelerating cyberattacks from intrusion to impact. Meanwhile, organisations can still take months to identify and contain a breach. Is making detection faster enough, or should we move the security decision to before execution begins?
For more than twenty years, cybersecurity has invested heavily in becoming better at detecting attacks.
It has become faster at identifying malicious software, better at correlating events, better at collecting telemetry and increasingly capable of automating its response. Security operations centres now use artificial intelligence to distinguish genuine threats from background noise, endpoint products monitor behaviour and threat intelligence platforms constantly update what defenders know about attackers.
Yet the attacker still gets the first move.
That matters because the time available to detect and respond is collapsing. Palo Alto Networks Unit 42 examined more than 750 major cyber incidents in 2025 across more than 50 countries. Its 2026 Global Incident Response Report found that the fastest quarter of intrusions reached data exfiltration in 72 minutes. A year earlier, the equivalent figure was 285 minutes. In a simulated AI assisted attack, Unit 42 reduced the time to exfiltration to just 25 minutes. Attackers are also beginning to scan for newly announced vulnerabilities within 15 minutes of a CVE disclosure.
IBM’s 2025 Cost of a Data Breach Report shows the other side of the equation. While the fastest intrusions can progress from access to exfiltration in little more than an hour, organisations still took an average of 241 days to identify and contain a breach - a lifecycle measured in months, not minutes.
The problem is not limited to detection. The time available to assess, test and deploy a remedy has also come under increasing pressure. J.P. Morgan’s “Patchmageddon” report highlights the race to patch software vulnerabilities before zero-day cyber-exploitations proliferate. The report notes that the average time between disclosure of a vulnerability and first exploitation has fallen to a single day, leaving organisations little more time to react than residents of tornado alley. At the same time, organisations are taking longer to patch vulnerabilities, and in approximately 60% of breaches a patch was already available at the time of compromise.
The implication is significant. The patching timeline has collapsed: the traditional sequence of vulnerability discovery, patch development, testing and deployment can no longer be assumed to complete before exploitation begins.
The problem is particularly acute in operational technology and critical infrastructure. J.P. Morgan’s work with industrial organisations estimated that only a little more than half of industrial networks are patchable, while a material proportion have no patch available at all. In these environments, the question is not simply how quickly an organisation can patch. It is what protects the system when it cannot.
The World Economic Forum reaches a similar conclusion from a different direction. Its Global Cybersecurity Outlook 2026 describes an environment in which the speed and scale of attacks are testing the limits of traditional defences.
The conventional response to this problem is to make detection faster. Unit 42 argues that security operations must move at machine speed, using comprehensive telemetry, artificial intelligence and automated containment to identify and stop attacks before they can spread. Given the evidence presented in its report, that conclusion is understandable.
There is, however, another question worth asking. If an attack depends upon introducing or creating unauthorised executable code, why permit that code to execute and then race to identify what it is doing?
This creates a pre-detection exposure window: the period in which unauthorised code may execute before a vulnerability is known, a patch is available, or conventional controls have accumulated enough evidence to act. As the time available to remediate collapses, what protects the organisation in the meantime, particularly where critical systems cannot safely be patched?
One answer is to move the security decision earlier, before execution begins.
Abatis addresses this through Deterministic eXecution Integrity (DXI). Rather than attempting to determine whether executable code is malicious after it has started running, DXI determines whether that code is authorised to execute before the operating system completes the request. If the code is not authorised, it does not execute.
This is a different security question from that asked by traditional detection technologies. Endpoint detection and response platforms, threat intelligence systems and behavioural analysis tools seek to identify malicious activity by analysing evidence, patterns and behaviour. DXI does not attempt to classify the intent of the code. It determines whether the execution itself has been authorised.
By moving this decision point ahead of execution, DXI provides an additional integrity layer beneath existing security technologies. It does not replace detection, investigation or response capabilities. Instead, it protects against unauthorised executable activity during the period before conventional security controls can determine that an attack is underway.
Abatis enforces this decision within the operating system kernel, intercepting executable creation and execution requests before the operating system completes the operation. The decision is made locally and does not depend upon malware signatures, behavioural analysis, artificial intelligence, cloud connectivity or continuous threat intelligence.
Airbus Defence & Space evaluated Abatis in an Industrial Control System and SCADA environment and confirmed effective protection against unauthorised executable code, compatibility with existing security controls and suitability for legacy operational technology environments. Lockheed Martin undertook extensive technical evaluation and validated stable operation, low resource consumption and effective prevention of executable code introduction. Bank of America conducted an independent technical assessment in enterprise banking infrastructure, while Armasuisse evaluated the technology within the Swiss defence cyber research environment.
These evaluations were not simply assessments of malware detection capability. They examined the core proposition of deterministic execution integrity: whether unauthorised executable code could be prevented from running regardless of whether that code was previously known, classified or visible to conventional security tools.
Long term operational deployment provides a different form of evidence. Abatis has operated for many years in environments including European container terminals, nuclear infrastructure, transportation, energy and government systems.
The experience of Endeavour Insurance illustrates the distinction between prevention and detection. During a phishing campaign, malicious files bypassed existing security controls and reached a user. When execution was attempted, Abatis prevented the ransomware from running. In a separate incident, malware remained present on a terminal server for approximately sixteen weeks before conventional antivirus identified it. The significance was not that detection eventually failed; it eventually succeeded. The significance was that deterministic execution control provided protection during the period before detection caught up.
Where an attack depends upon unauthorised executable code, DXI can interrupt the attack path at the point execution is requested. The malware does not first need to run, create behavioural signals, establish persistence, spread across the environment or trigger an incident response process before a decision is made.
This does not mean that every form of compromise disappears. Stolen credentials, misuse of legitimate applications, SaaS activity and other non executable attack paths still require identity security, monitoring, detection and response. However, where an attacker needs to introduce or execute unauthorised code, the customer should not have to wait for that code to generate an incident before protection begins.
The significance of this approach becomes clearer when considered alongside the Unit 42 findings. If exploitation begins within minutes of a vulnerability being disclosed and some intrusions progress from access to exfiltration in little more than an hour, the interval available for observation, classification, investigation and containment is becoming very short. Making those processes faster is valuable, but it does not alter their sequence. Something happens, the security system observes it, decides whether it is dangerous and then acts.
For attacks that require unauthorised executable code, DXI changes that sequence because the authorisation decision occurs before execution.
Artificial intelligence makes this distinction increasingly relevant. AI is improving established attack techniques, helping attackers automate reconnaissance, generate malicious scripts and adapt their tools more quickly.
This presents a particular problem for technologies whose effectiveness depends upon recognising malicious software or behaviour. Artificial intelligence makes it easier to produce new variations of software and techniques at scale. A previously unseen executable may have no known signature and its behaviour may differ from earlier examples.
Deterministic execution control approaches the same problem differently. Whether an attacker produces one malicious executable or thousands of previously unseen variants does not change the underlying policy decision. If the executable has not been authorised to run, it is prevented from doing so.
The same distinction is relevant to the software supply chain. The World Economic Forum identified the inability to assure the integrity of third party software, hardware and services as the leading supply chain concern.
A trusted delivery mechanism should not confer automatic trust upon everything delivered through it. A compromised supplier, malicious update, stolen administrator account or remote management system may provide an attacker with a legitimate route into an organisation. The important question is what the attacker is then permitted to change or execute.
DXI does not remove the need for identity security, network security, endpoint detection, SaaS controls or incident response. Its purpose is different. It provides a separate execution integrity control.
An attacker may acquire valid credentials and gain access to a system, but possession of an identity need not automatically confer the ability to introduce and execute arbitrary software.
The prevailing answer to modern cyber threats has been to detect faster, analyse faster and respond faster. Those capabilities remain necessary. They should not, however, be the only answer.
Abatis has spent more than twenty years applying a different principle to executable integrity: determine whether execution is authorised before allowing it to occur. The technology has been independently evaluated by defence, banking and industrial organisations and has operated for many years in environments where stability and availability are critical.
The significance of that approach is increasing because attackers are consuming the time available for detection and response faster than before. As attack processes increasingly become automated, a security architecture that depends entirely upon recognising and responding to malicious activity after it has begun is committing itself to a race against machines.
There will always be attacks that have to be detected and incidents that have to be contained. There will always be a requirement for organisations to recover when preventative controls fail.
Sun Tzu wrote that: “The good fighters of old first put themselves beyond the possibility of defeat, and then waited for an opportunity of defeating the enemy.”
Modern cybersecurity has largely focused on improving the ability to recognise and respond to attacks after they begin. That capability remains essential. No defensive architecture eliminates every threat.
However, the strategic question is whether organisations should always allow the attacker to make the first move.
Where executable code is concerned, deterministic prevention changes that equation. It moves the security decision from identifying malicious activity after execution has started to determining whether execution should be permitted in the first place.
The objective is not to win every battle after the attacker has entered the field. It is to make certain classes of attack more difficult to succeed before the battle begins.
Categories
Recent Posts
This site uses cookies to provide you with the best experience on our website. Please, accept cookies for optimal performance. For full details, see our Privacy Policy