Indigenous Defence Software and the Future of Atmanirbhar Bharat

Indigenous defence software is now a first-order Atmanirbhar Bharat concern, not a footnote to platform manufacturing. On 10 February 2026, the Ministry of Defence released the draft Defence Acquisition Procedure 2026, requiring Indian ownership of source code, critical technical data and upgrade authority. The next capital procurement cycle opens on 1 April 2026 under those terms (Ministry of Defence, 10 February 2026). This piece maps the imperative through the sovereign-code, sovereign-substrate and sovereign-governance triad that defines Atmanirbhar Bharat for software.

Locating software inside the Atmanirbhar Bharat doctrine

Atmanirbhar Bharat for software means Indian control over the code, computing environment and governance that decide how defence systems behave. Manufacturing a platform inside India does not automatically transfer control of its mission software, interfaces or upgrade path.

The Ministry of Defence has treated indigenous design as a procurement objective through DAP 2020, Positive Indigenisation Lists, SRIJAN and Innovations for Defence Excellence. The first Positive Indigenisation List for Defence Public Sector Undertakings contained 2,851 items. SRIJAN was built to connect imported defence items with Indian industry (Ministry of Defence, 14 March 2022). Those tools built an important manufacturing pipeline.

They did not build an equivalent software pipeline. A software component can remain foreign-controlled even when the box housing the processor, radio or mission computer is assembled in India. The Positive Indigenisation Lists count metal, not code.

The sovereign-code, sovereign-substrate and sovereign-governance triad closes that gap. Sovereign code covers mission logic, applications and algorithms. Sovereign substrate covers the operating environment, communications, cryptography and compute layer. Sovereign governance covers procurement rights, intellectual property, assurance and the workforce needed to sustain the system.

Hardware ownership determines who builds the physical system. Software sovereignty determines who can inspect, modify, secure and upgrade the behaviour of that system. This distinction now sits inside the Atmanirbhar Bharat defence software agenda, alongside the hardware-first push that shaped the country's self-reliant drone industry and every earlier indigenisation cycle.

The Prime Minister's Independence Day address in 2025 described indigenous defence capability as a foundation of national strength. That address linked self-reliance in defence with technology, space and energy (Prime Minister's Office, 15 August 2025). The next step is to apply that principle to code with the same precision already applied to manufactured components.

Reading the DAP draft as a code-ownership document

The draft Defence Acquisition Procedure moves procurement from where equipment is manufactured to who owns the design and can control its evolution. The Ministry of Defence released the draft on 10 February 2026, running to two volumes and roughly 800 pages. The consultation window closed on 3 March 2026 (Ministry of Defence, 10 February 2026).

The draft ties Indigenous Design to Indian ownership of design documents, source code, system architecture and design data, rather than domestic manufacture alone. The Ministry has framed the direction as a move from "Made in India" to "Owned by India" (Ministry of Defence, 10 February 2026).

That framing rewrites the DAP 2026 source code ownership question. The relevant test is no longer whether an Indian entity can manufacture a system. The test becomes whether that entity possesses enough technical control to sustain, secure and modify the system through its operational life.

The draft also raises the Indigenous Content requirement under Buy (Indian-IDDM), Indigenously Designed, Developed and Manufactured, from 50 percent under DAP 2020 to at least 60 percent. Foreign vendors supplying equipment under Buy (Global) were previously exempt from any indigenous content floor. The draft requires them to ensure 30 percent Indigenous Content in their products (Ministry of Defence, 10 February 2026).

DAP 2020 established a strong domestic procurement and manufacturing preference. The draft DAP 2026 adds a stronger ownership test around Indigenous Design and intellectual property.

That distinction creates the owned by India defence procurement question. An Indian factory, Indian workforce and Indian final assembly are not enough if the underlying architecture remains outside Indian control.

The draft also sits beside the Defence Procurement Manual 2025, which governs maintenance and sustenance under the Revenue head. DAP governs capital procurement under the Capital head (Ministry of Defence, 10 February 2026). For software, that boundary matters. Capital acquisition can establish ownership requirements, but long-term sovereignty depends on whether those rights survive upgrades, maintenance contracts, cybersecurity remediation and technology refresh cycles.

Mapping the sovereign code stack for India's armed forces

The sovereign code stack is a three-layer model. It separates mission software, its technical substrate and the governance system controlling both.

Layer 1 is where operational behaviour is encoded. It includes mission computers, sensor-fusion software, battle-management applications, route planning, computer vision and autonomous functions.

Layer 2 determines whether Layer 1 can run securely and independently. An Indian-developed application still carries dependency risk if its operating environment, cryptographic implementation, middleware or communications stack cannot be inspected or modified by authorised Indian entities.

Layer 3 governs the relationship between the first two layers. Procurement clauses determine ownership. Security organisations determine assurance. Engineering teams determine whether ownership can be exercised after delivery.

The question is no longer whether India can build the box. The question is whether India controls the code inside it.

This is why sovereign code India cannot mean source-code ownership alone. Source code without build systems, technical documentation, test infrastructure and qualified engineers is an unusable asset.

The same principle applies to Indian defence AI. A model is not sovereign if the mission workflow depends on inaccessible foreign inference infrastructure, proprietary interfaces or an external update chain. Kodainya has explored the same tension in depth for AI in Indian defence modernisation.

A sovereign stack therefore requires control across the entire lifecycle. Design, build, test, deploy, monitor, patch and upgrade must form an Indian-controlled engineering loop.

Owning the mission logic across platforms and payloads

Indigenous mission software India refers to the code that converts sensors, platform data and mission objectives into operational functions. That software layer now connects aircraft, unmanned systems, weapons, communications and command networks.

DRDO's Centre for Artificial Intelligence and Robotics, CAIR, provides an established Indian example. The laboratory was set up in 1986 and works across artificial intelligence, robotics, command and control, networking, information security and unmanned systems (DRDO, 2026). CAIR's NETRA network-traffic analysis suite, built for Indian intelligence agencies, is one of the clearest proof points that indigenous defence software already ships at production scale.

The importance of this history is architectural. Mission software is not a recent addition to Indian defence technology. Indian laboratories have spent decades developing software for command, control, robotics and battlefield information.

The next requirement is scale and integration. A modern mission computer can combine radar tracks, electro-optical feeds, navigation data, communications and other sensor inputs. Computer vision can classify objects and sensor fusion can correlate measurements. Edge inference can process data without moving every workload to a remote server.

Autonomy raises the requirement further. An autonomous function may perform target classification, route planning or navigation without per-step human control, an area covered in depth for autonomous drones in India. An automated function follows predefined logic, while an autonomous function can select actions within an authorised mission framework.

The distinction matters for procurement. If mission logic is supplied as a closed component, Indian operators receive a capability without the engineering control needed to modify it.

The AMCA fighter jet and other future Indian combat-air programmes make this issue harder because software will connect flight systems, sensors, weapons, communications and mission systems. Existing indigenous aircraft programmes, including the HAL Tejas, already demonstrate that software ownership is a long-duration engineering responsibility. The mission software layer should therefore be treated as a national engineering asset with the same lifecycle attention given to airframes, engines and weapons integration.

Indigenising the operating substrate and cryptography

The sovereign substrate is the technical environment that allows defence software to execute securely, communicate reliably and remain maintainable across its service life. It includes operating systems, middleware, compute, networking, cryptography, identity and security controls.

A software application can be written in India while remaining dependent on foreign-controlled substrate components. That dependency can affect vulnerability management, patching, certification, interoperability and long-term support.

Cryptography creates an additional sovereignty boundary. Defence networks require controlled implementation, key management, secure communications and assurance across hardware and software. Ownership of an application does not automatically provide control over the security mechanisms below it.

The Defence Cyber Agency, established in 2019 under the Integrated Defence Staff, therefore sits inside the software sovereignty discussion rather than beside it. Its role places cyber defence within the military command structure rather than treating cybersecurity as an external information-technology function.

The substrate also determines how artificial intelligence reaches the field. Edge inference requires compute resources, accelerators, operating environments and secure data pipelines. Sensor fusion requires interfaces that can exchange trusted information between systems.

That is why software indigenisation cannot stop at application development. A sovereign application running on an opaque substrate still leaves an operational dependency.

India's defence software strategy therefore needs a layered assurance model. The code must be inspectable and the build chain must be controlled. Dependencies must be recorded and cryptographic functions must operate within approved security architectures. Updates must be authenticated and traceable.

The working definition of sovereign software follows from that model. India owns the code, controls the substrate and can verify every material dependency that affects mission performance or security.

Building a sovereign command and control fabric

A sovereign command and control fabric connects sensors, effectors, operators and decision-support applications across the force. C4ISR India indigenous capability, Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance, depends on software. The value of each sensor rises when its information can move through a trusted network.

India's Defence Forces Vision 2047 places integration and multi-domain capability at the centre of military transformation. Headquarters Integrated Defence Staff released the document on 10 March 2026, describing a future force designed around integration, technology and multi-domain operations (Ministry of Defence, 10 March 2026).

That direction raises the importance of indigenous command software. A command-and-control system must correlate information, maintain track identity, distribute alerts and present operational information to authorised users.

The software layer also connects platforms. Air defence, unmanned systems, electronic warfare, maritime surveillance and battlefield networks can generate data through different interfaces. Without common architecture, each additional platform creates another integration boundary.

India's indigenous software challenge is therefore not simply to build individual applications. It is to create interfaces and data structures that allow systems to work together.

The Akashteer air defence system demonstrates the software-defined direction of Indian air defence. The Combat Air Teaming System shows how manned-unmanned integration will depend on Indian mission software. The broader lesson is architectural: command software gains value when it can integrate sensors and effectors across a network rather than operate as an isolated application. Kodainya has covered the parallel evolution of AI battle management in India in a dedicated cluster piece.

Sovereign command and control India therefore means more than an Indian-built command console. It means India controls the software interfaces, data pathways and upgrade mechanisms that connect the force.

Verifying trust through the Defence Cyber Agency and audit gates

Software sovereignty requires an assurance institution capable of verifying what has been acquired. The Defence Cyber Agency, operating within the Integrated Defence Staff structure, provides that institutional anchor.

The assurance problem begins before deployment. Procurement teams need visibility into software architecture, dependencies, update mechanisms and security controls. Operators then need processes to detect vulnerabilities, validate patches and maintain configuration control, an operational discipline explored in India's drone cybersecurity framework.

DAP 2026's emphasis on Indigenous Design strengthens this requirement because ownership must be technically meaningful. An Indian entity cannot exercise meaningful control over software that it cannot inspect, build or modify.

The audit gate should therefore cover the complete software supply chain. Source-code access is one gate. Build reproducibility is another. Dependency inventories, vulnerability management, cryptographic controls and update signing provide additional gates.

This changes how defence contracts should treat upgrades. A system delivered in year one can remain in service for decades. Software vulnerabilities, operating environments and mission requirements will change during that period.

The Ministry of Defence has already separated capital acquisition from revenue-side maintenance and sustenance. That split runs through DAP 2026 and the Defence Procurement Manual 2025 (Ministry of Defence, 10 February 2026). The software sovereignty question must extend across both phases.

An assurance framework should therefore connect procurement, cybersecurity and sustainment. The same technical ownership established at acquisition must remain enforceable when software is patched, upgraded or integrated with another system.

The result is a governance layer that treats software as an operational asset. Auditability is not paperwork. It is the mechanism that turns contractual ownership into usable engineering control.

Closing the software indigenisation-list gap inside procurement

India's Positive Indigenisation Lists created a structured mechanism for identifying defence items that should move away from imports. The first DPSU list contained 2,851 items, and subsequent lists expanded the manufacturing indigenisation pipeline (Ministry of Defence, 14 March 2022). The software indigenisation list gap is that this framework does not yet provide an equivalent taxonomy for mission applications, middleware, operating environments, cybersecurity components and software interfaces.

That gap is measurable through the structure of existing policy. The SRIJAN portal was built to help Indian industry identify imported defence items (Ministry of Defence, 14 March 2022). It offers a policy mechanism that could support a software-focused extension.

A positive indigenisation list software framework could classify dependencies by operational function. Mission planning, battle management, sensor fusion, secure communications, electronic support, autonomy, simulation and maintenance software could each become identifiable capability areas.

The purpose is not to ban every foreign software component. It is to identify dependencies that create operational, security or upgrade risk and establish an Indian development path for them.

This distinction is important. Defence software indigenisation should prioritise mission-essential dependencies rather than attempt to reproduce every commercial software component.

The Department of Defence Production already has an innovation and procurement ecosystem that connects iDEX, startups, MSMEs and the Services. SRIJAN adds an import-substitution interface. DRDO laboratories provide research capability. DAP provides the procurement mechanism.

The missing layer is a systematic software taxonomy connecting those mechanisms. Without that taxonomy, procurement can measure indigenous content while overlooking software dependencies that determine operational control. A software-focused indigenisation list would make the gap visible. Visibility is the first procurement requirement for closing it.

Scaling delivery through iDEX, DRDO CAIR and DPSU code labs

iDEX defence software can provide the delivery pipeline needed to convert software sovereignty from procurement language into deployable capability. The iDEX scheme supports startups and MSMEs and provides a procurement route under the defence acquisition framework (Department of Defence Production, 2026).

The iDEX funding structure gives software companies a route into defence development. The programme provides grants of up to Rs 1.5 crore through its standard framework. iDEX Prime supports projects up to Rs 10 crore (Department of Defence Production, 2026).

That pipeline matters because defence software requires more than a prototype. A mission application must pass integration, cybersecurity, testing, certification, operator evaluation and sustainment gates.

DRDO CAIR indigenous software has already demonstrated the research foundation. Its work spans artificial intelligence, robotics, command and control, networking, information security and unmanned systems. The CAIR-built NETRA product is a working example of production-grade Indian defence software (DRDO, 2026).

The next stage is to connect research with repeatable delivery. DPSU software teams, DRDO laboratories, Services and Indian startups can operate as different parts of one engineering ecosystem.

The Defence Innovation Organisation, DIO, is central to the iDEX structure. The model gives startups a route from challenge definition through development and potential procurement, reducing the gap between innovation activity and military adoption.

AI belongs inside this pipeline. A defence software startup can build computer vision, sensor fusion or mission-planning capability, but operational value appears only after integration with real sensors, communications and command systems.

This is where the sovereign-code model becomes practical. The development contract should define ownership and the integration environment should expose interfaces. The assurance process should test the software, and the procurement mechanism should preserve upgrade authority.

India does not need a single organisation to write all defence software. It needs a national delivery architecture in which Indian entities can build, integrate, secure and sustain the software that matters.

Testing the doctrine on the Rafale source-code question

The Rafale case shows why software sovereignty must distinguish between platform procurement, technology transfer and source-code ownership. India and France signed an agreement in April 2025 for 26 naval aircraft. The deal included technology transfer for integration of indigenous weapons, plus Indian facilities for selected manufacturing and maintenance activities (Ministry of Defence, 28 April 2025).

The subsequent MRFA process creates a harder policy test. On 12 February 2026, the Defence Acquisition Council granted Acceptance of Necessity for the 114-aircraft Multi Role Fighter Aircraft requirement. The Ministry of Defence stated that the fleet would be predominantly built in India (Ministry of Defence, 12 February 2026).

The important India Rafale source code question is not whether every foreign platform must surrender every line of software. That would confuse ownership with operational sovereignty. The sharper question is which interfaces, design data and software rights India requires to integrate weapons, sensors, communications and future indigenous systems without external engineering dependence.

The primary sources establish Indian manufacturing, technology-transfer and indigenous-weapons integration provisions. They do not establish a public transfer of complete source code for the aircraft, and that distinction should remain explicit.

This is where the software sovereignty India doctrine becomes useful. Indigenous Design requires Indian ownership of source code, system architecture and technical data for qualifying indigenous systems (Ministry of Defence, 10 February 2026). The principle is directly applicable to Indian-designed capabilities. Foreign-origin platforms can then be evaluated through a different lens: which interfaces and technical data are necessary to preserve Indian integration authority.

Software sovereignty therefore does not mean rejecting foreign equipment. It means preventing foreign equipment from becoming an unmodifiable boundary around Indian systems.

Preparing the cleared-engineer workforce that the stack demands

A sovereign software stack requires engineers who can build, audit and sustain mission systems inside India's security framework. Procurement ownership has limited value if the country lacks the cleared technical workforce needed to exercise that ownership.

The skill requirement extends beyond conventional application development. Defence software teams need expertise in real-time systems, embedded computing, secure networking, cryptography, distributed systems, computer vision, sensor fusion and artificial intelligence.

CAIR's history illustrates the depth of the requirement. DRDO has worked on robotics, command and control, battlefield communication, sensor fusion and information security through the laboratory since its establishment in 1986 (DRDO, 2026).

The next workforce layer must connect these disciplines. A software engineer working on a mission computer needs to understand timing, interfaces and platform constraints. A cybersecurity engineer needs to understand the operational environment, and an AI engineer needs to understand sensor characteristics and failure modes.

Clearance processes also affect delivery speed. Defence organisations need a sustainable pipeline for engineers who can work with protected information, secure development environments and controlled technical data.

That workforce should exist across DRDO, DPSUs, Services, startups and specialised defence-technology companies. A single institutional talent pool cannot support every programme.

The objective is a cleared-engineer defence workforce capable of retaining institutional knowledge through decades-long programmes. That workforce is part of the sovereign substrate because human engineering capacity determines whether software ownership remains meaningful after the original development contract ends.

Charting the next twelve months for Indian defence software

The next twelve months will test whether software sovereignty becomes a procurement practice or remains a policy principle. The draft DAP 2026 was released on 10 February 2026, with stakeholder comments invited until 3 March 2026. The final framework is intended to replace DAP 2020 (Ministry of Defence, 10 February 2026).

Three signals are worth tracking on the near horizon. The first is the final treatment of Indigenous Design in the notified DAP 2026 text. The second is how source code, system architecture and technical data are interpreted during the FY 2026-27 capital cycle that opens on 1 April 2026. The third is whether a software-focused Positive Indigenisation List follows the four hardware lists already notified.

The iDEX pipeline will also matter. Defence software needs development challenges defined around operational problems, not generic technology themes. Funding must connect to integration environments, user trials and procurement pathways.

The Defence Cyber Agency will grow in importance as the Indian software base expands. More indigenous code means more code that Indian military cybersecurity organisations must assess, monitor and protect.

India's Defence Forces Vision 2047 also places integration and technology at the centre of military transformation (Ministry of Defence, 10 March 2026). That transformation cannot be software-neutral, and Atmanirbhar Bharat's hardware-indigenisation architecture now needs an equivalent architecture for code.