In recent years, the cybersecurity landscape has been characterized by an increasingly sophisticated array of threats [1], necessitating the evolution of defence mechanisms that can adequately protect digital assets and communications. Traditional security protocols, heavily reliant on centralized models, have shown vulnerabilities, particularly in the face of advanced persistent threats and the looming advent of quantum computing [2]. The concept of zero-trust architecture has emerged as a foundational principle in designing more secure systems
kin: Rapidly Deployable Quantum-Resistant, Fully Decentralized Authentication and Encryption for Beyond Zero-Trust Networking in Disparate Complex Networks
As we increasingly embed connectivity into the very fabric of our societies, economies, and infrastructures, the security of these connections and the authenticity and integrity of data exchanged become paramount. The prevailing centralized nonquantum- safe models for authenticating and securing digital assets and communications, though functional, present singular points of vulnerability and failure. These centralized systems, acting as hubs of critical data, inherently draw malicious intent and become attractive targets for an array of cyber-attacks
Leveraging the Decentralised Open IoT Security Protocol kin: Facilitating Edge-Based Artificial Intelligence in Large-Scale Network Infrastructures
The truly autonomous, intelligent world envisioned by many in both academic and non-academic circles is contingent upon every relevant “thing” or asset communicating to every other relevant “thing” securely in real-time. This a rapidly developing paradigm shift characterized by an enormous number of nodes, many of which are low powered and connected by diverse multiple operating systems and communication protocols. In essence, these connections drive the connection between the digital and physical worlds, collecting data and implementing actions on people and things in contexts ranging from autonomous vehicle control, delivery of vital environmental commodities such and electricity and water, environmental monitoring, energy production, military offense and defense, aerospace, production of and delivery of commercial items, and health care monitoring and treatment
Fully Decentralized Post-Quantum Resistant Authentication, Encryption Protocol with Full Data Interoperability Universally Deployable in any Network Environment
This document provides an account of Attack Vector Mitigation in dOISP™v6.0. It assumes that the reader is familiar with the workflows and protection mechanisms of Iothic’s decentralised Open Interoperability Security Protocol (dOISP™).
Attack Vector Mitigation in dOISP™
Why machine-to-machine security needs trust that is proven by architecture, not added through credentials
Zero Trust should not have to depend on a stack of inherited assumptions.
For many organizations, Zero Trust is still treated as an implementation project. Policies are written. Access tools are added. Identity systems are connected. Certificates, keys, tokens, and privileged accounts are managed more tightly. Those steps can improve security, but they often leave the same underlying structural problem: the environment still trusts something that was issued, stored, or approved earlier.
Advancing Protection of SASE
By Mykhailo Magal, PhD, Head of Research and Development, Iothic Ltd.
How kin strengthens edge-cloud-edge security with Continuous Proof Trust
Secure Access Service Edge changed how organizations think about network security. It brought together identity, policy enforcement, traffic inspection, cloud-delivered access, and software-defined connectivity into a more flexible model for users, applications, branches, cloud services, and edge environments.
Zero Trust by Design and Default
By Mykhailo Magal, PhD, Head of Research and Development, Iothic Ltd.
A standard for proving machine trust without stored credentials
The industry has spent decades trying to protect credentials. Continuous Proof Trust starts from a different assumption: trust should be proven in the moment, not stored for later.
Trust Shouldn’t Be Inherited
The Problem with Inherited Trust
Every connected system has to decide what it will trust next. That decision should belong to the moment in front of it. Instead, much of modern security still relies on trust that carries over from earlier events.
A credential was issued. A certificate was accepted. A token was granted. A session was opened. A device was enrolled. From that point on, the system often behaves as if the original proof still says enough about the current interaction.
That is inherited trust. It is not always obvious because it hides inside normal architecture. The system is not necessarily broken. The credential may be valid. The certificate may be current. The tunnel may be encrypted. The device may have passed its earlier check. The problem is that yesterday's proof is being allowed to answer today's question. Worse yet, the proof from 364 days ago is still in use today.
In a slower world, that was a reasonable compromise. In a connected, automated, machine-speed environment, it becomes a structural risk and a significant vulnerability
CNSA 2.0 Is Quietly Exposing the Real Problem with Machine Trust
By Mykhailo Magal, PhD, Head of Research and Development, Iothic Ltd.
CNSA 2.0 is often discussed as a cryptography deadline. That is understandable. The move away from quantum-vulnerable public key algorithms is a major shift, and the new post-quantum standards matter.
But if the conversation stops at algorithms, it misses the larger issue. The post-quantum transition is forcing organizations to confront how machines establish trust in the first place.
Most systems still rely on objects that must be stored and later trusted: certificates, keys, tokens, shared secrets, static identities, and trust anchors. Those objects need to be issued, protected, rotated, revoked, audited, and eventually replaced. The larger and more distributed the environment becomes, the harder it is to defend.
CNSA 2.0 pulls on that thread. It not only asks whether the cryptography is strong enough. It asks whether the trust architecture underneath the product can survive the next era of security expectations.
Protecting Critical Infrastructure
Critical infrastructure was built to keep operating.
Water treatment plants, power generation sites, electrical substations, traffic control systems, rail networks, ports, airports, and emergency services were designed around availability, safety, reliability, and continuity. In many cases, the systems that run them were built long before today’s threat environment existed.
That creates a difficult problem. The systems society depends on most are often the hardest to change. A PLC running part of a water treatment process may be too old to support modern security software. A substation device may be under warranty, certified, or too operationally sensitive to modify. A traffic control system may rely on equipment designed to communicate within a trusted municipal network, not across today’s connected infrastructure.
Security teams know these systems need stronger protection. Operators know they cannot risk disrupting them.
Continuous Proof Trust
