Who Owns the Brain? The Case for a Sovereign Operating System

India builds hardware. But the software layer running on that hardware, the part that decides what the system does, how it responds, what it trusts, often belongs to someone else entirely.

The layer most people overlook

When we talk about building technology sovereignty, most of the conversation is about hardware. Chips, processors, fabrication facilities. That is the right instinct and the right investment. But there is a layer below the application and above the silicon that rarely gets the same attention: the operating system.

An operating system, specifically a real-time operating system (RTOS) in an embedded or safety-critical context, is not just software you install. It is the control layer. It decides which process gets CPU time and when. It manages memory access. It handles hardware interrupts. It enforces security boundaries between components. In a drone, a satellite, an avionics system, or a medical device, the RTOS is the layer that determines whether the system behaves exactly as designed, under every condition, without failure.

When that layer is a proprietary, foreign-owned product, you do not fully control the system running on it. You control the application layer. The foundation belongs to someone else.

"Sovereignty is an illusion without control over the stack." — Sridhar Vembu, CEO, Zoho Corp

The supply chain problem is already visible

In February 2025, India's defence establishment cancelled procurement contracts worth ₹230 crore covering 400 logistics drones. The reason: components from foreign sources had been found embedded in drones marketed as indigenous, raising concerns about data security, potential backdoors, and operational integrity.

A senior defence official noted at the time: the use of such components poses a major cybersecurity threat, with potential for data breaches, operational compromise, and even hostile takeover of drone systems.

This incident captured the hardware dimension of the supply chain problem. But it pointed to something deeper. Even where the physical components are indigenous, the software stack running on top, including the kernel, the firmware, the communication protocols, may have foreign dependencies that are not tracked in procurement documentation and not visible to operators in the field.

Source: India Today, 'Army cancels Rs 230 crore drone contracts over alleged use of Chinese components,' February 7, 2025 —

Source: DefenceXP, 'Make in India drones hacked' —

What a proprietary RTOS actually means

Most safety-critical platforms today run on one of a small number of commercial real-time operating systems. These are mature, capable products. They are also closed: you cannot audit the source code, you cannot verify what the kernel is doing at the hardware level, and you cannot modify its behaviour without going through the vendor.

Licensing these systems also means accepting the vendor's update cycle, their support contract terms, and the possibility that geopolitical or legal decisions outside your control could affect your access to patches, certifications, or continued support. When sanctions or export restrictions are applied, software licenses are among the first things affected. The Nayara Energy case in 2025, where a proprietary software vendor's compliance with external sanctions froze access to strategic data, illustrated this clearly.

Source: MediaNama, 'Microsoft Blocks Nayara Data,' 2025 —

Open source alone is not the answer

The obvious response is: use open-source software. If you have the source code, you can audit it. This is correct as far as it goes. But in safety-critical domains, having the source is not the same as owning the stack.

A widely used open-source kernel like Linux has over 27 million lines of code. It receives thousands of code contributions every week from engineers across the world. Auditing it fully is not practically feasible. More importantly, for safety-critical certification standards like DO-178C Level A in aerospace or ISO 26262 ASIL-D in automotive, the certification evidence package, including formal proofs of correctness, must be generated and owned by the organisation deploying the system. A general-purpose kernel that was not designed for formal verification cannot be certified to these levels.

India's defence, space, and aerospace programmes increasingly need systems certified to exactly these standards. A deployment-grade, certifiable, formally verified RTOS requires a kernel that was designed with verification in mind from the start.

What we are building

RedKill OS is India's first safety-critical, verification-ready, open-source RTOS. It is built from scratch, not derived from any existing kernel. It is hardware-agnostic, running on ARM64, RISC-V64, and SPARC V8 architectures, and has been silicon-validated on both the AJIT processor, India's indigenous microprocessor developed at IIT Bombay, and standard ARM64 cores.

The architecture uses modular partitioning with formal isolation boundaries, a design approach that makes the trusted computing base small enough to formally verify. The system is being built toward ISO 26262 ASIL-D and DO-178C Level A compliance.

RedKill is pre-incubated at SINE, IIT Bombay, and is under contract with India's National Supercomputing Mission to deliver customised OS software for advanced hardware platforms.

The point is not that India lacks hardware ambition. The point is that hardware ambition without OS sovereignty leaves a gap in the stack that matters precisely when stakes are highest.