Bharat’s Tech Sovereignty Partnerships in Africa and ASEAN

If the headline number you saw was 24 MoUs, your real question is probably harder: do these agreements give partner countries more command over their digital future, or do they merely change the foreign supplier? You cannot answer that by counting signatures.

For Africa and ASEAN, the useful test is control. Follow who sets the rules, holds the data, operates the infrastructure, changes the code and can replace a provider. That turns technology sovereignty from a diplomatic slogan into something you can evaluate.

The 24 MoUs are a starting line, not a sovereignty score

By early August 2026, the Union government had informed Lok Sabha that Bharat had signed technology-cooperation MoUs with 24 countries. The change is significant because New Delhi is moving beyond broad digital-cooperation language toward exporting working technological capabilities.

But an MoU records intent. It does not tell you whether a platform is operating, whether local institutions can maintain it or whether the partner country has gained meaningful autonomy. Public discussion often compresses negotiation, pilot, deployment and national adoption into the single word partnership. Keep those stages separate.

Before treating any agreement as an advance in sovereignty, ask five questions:

• Rule-making: Can the partner’s own institutions decide how the system works and who may use it?
• Data authority: Who determines where sensitive records are held, who can access them and how misuse is investigated?
• Technical authority: Can an authorised local team configure, audit, patch and extend the system?
• Operational capacity: Can local institutions keep essential services running without waiting for a foreign implementation team?
• Exit power: Can the country move its data and services to another provider without breaking public access?

A partnership that transfers only software may still deepen dependency. A partnership that transfers decision rights, operational knowledge and a credible exit route is much closer to technology sovereignty.

Africa and ASEAN require different partnership designs

Bharat’s 2023 G20 presidency placed Digital Public Infrastructure in the New Delhi Leaders’ Declaration, giving DPI a larger role in Global South diplomacy. Africa has since become a central arena for Bharat’s foundational DPI engagement. ASEAN presents another setting: a highly digitised, fast-growing market where new modules must meet systems that are already established.

That distinction is strategic, not a ranking of regions. Nor should it be mistaken for a claim that every African or ASEAN country has the same needs. It tells you what the first partnership question should be.

In an African foundational deployment, governance and operations should be designed at the same time as the platform. If training, maintenance authority and data rules are postponed until after installation, dependency is being built into the foundation.

In ASEAN, the first practical task is different. Map the systems, interfaces, domestic institutions and regulatory constraints already present. A sovereignty-oriented offer should fit into that environment through clearly documented modules. It should not assume that Bharat’s domestic architecture can simply be transplanted.

If exactly the same proposal can be delivered unchanged in both regions, it probably has not gone far enough into either partner’s needs.

Open-source architecture helps, but it does not settle control

DPI consists of foundational digital capabilities on which public and private services can be built. Bharat’s domestic experience with India Stack supplies the diplomatic and technical confidence behind this push. MOSIP, the Modular Open Source Identity Platform, is especially important because Bharat is using it to pursue modular, open-source digital infrastructure beyond its borders.

Modularity can let a partner adopt one capability without importing an entire technological estate. Open source can permit inspection, adaptation and continued use beyond a single vendor relationship. These are real advantages.

Yet access to a code repository is not the same as the ability to govern a production system. A nominally open platform can remain externally dependent if local teams lack build instructions, deployment authority, documentation, security processes or the legal right to operate a modified version.

When you assess an open-source DPI partnership, look for a complete control package:

• The source code and the practical documentation needed to build and release it.
• Clear rights to deploy, modify, audit and, when necessary, fork the relevant components.
• Local institutional authority over production configuration, credentials and cryptographic keys.
• Documented interfaces and data structures that allow integration with domestic systems.
• A defined process for security updates, incident response and responsibility when failures occur.
• Training measured by what the local team can operate independently, not by attendance at workshops.
• A tested procedure for exporting data, migrating services and rolling back a failed change.

Test portability before production, using non-live or synthetic data. Waiting until a dispute or service failure to discover that records cannot be moved safely puts both public access and sensitive information at risk.

Use digital swaraj as the audit standard

Digital swaraj is a harder standard than Indian ownership or Indian origin. The nationality of the supplier does not, by itself, tell you whether the receiving country is sovereign. If one external dependency is replaced by another, the geopolitical flag has changed but the structural problem has not.

A Dharmic outlook should value agency, reciprocity and responsible stewardship. Applied to digital diplomacy, that means Bharat succeeds when a partner gains the practical capacity to govern essential infrastructure in accordance with its own laws, languages, institutions and public priorities. The goal should be capable partners, not captive markets.

You can audit an announced partnership through six gates:

1. Name the stage. Is this an MoU, a technical assessment, a pilot, a limited deployment or a production service? Do not credit one stage with evidence that belongs to another.
2. Map decision rights. Identify who approves changes, sets operating rules, grants access and adjudicates failures. A local institution should not be merely ceremonial while a foreign contractor makes the consequential decisions.
3. Trace data authority. Look for clear responsibility over collection, access, retention, transfer, deletion, audit logs and citizen redress under the partner country’s law.
4. Test technical independence. Ask whether authorised local teams can deploy, patch, integrate and recover the platform without compulsory vendor intervention.
5. Verify capacity transfer. Training should culminate in local operation of real functions. Workshop counts and certificates do not demonstrate that a country can run the infrastructure.
6. Examine exit and accountability. A partner should be able to retrieve its data, change implementers, commission an independent audit and keep essential services available during a transition.

Do not collapse these gates into one convenient score. A project may have open code but weak data governance. It may be locally hosted but impossible for local engineers to maintain. It may work technically while leaving citizens without a usable correction or grievance process.

The standard should also match the stage. An exploratory MoU cannot provide production uptime evidence, but its public description can still identify the intended module, responsible institutions, governance work and next decision point. Precision at an early stage prevents diplomacy from outrunning delivery.

For the next partnership announcement, make a three-column note: what capability is promised, what control is transferred and what evidence is public. An empty third column does not prove failure. It means the claim remains unverified and should not yet be presented as sovereignty achieved.

Key takeaways

• The 24 MoUs mark Bharat’s movement toward tangible technology exports, but agreement counts do not measure operational sovereignty.
• Africa’s foundational-infrastructure needs call for institution-building alongside deployment; ASEAN’s established digital markets call for modular interoperability.
• India Stack and MOSIP give Bharat a credible open and modular approach, but open source alone does not transfer operational control.
• Digital swaraj is visible in decision rights, data authority, maintainable technology, local capacity, accountability and a credible exit path.
• Every public claim should identify its lifecycle stage and the evidence appropriate to that stage.

The next time you encounter another DPI MoU, do not ask only what Bharat will export. Ask what the partner will be able to govern after the implementation team leaves. If the answer identifies local authority, controlled data, maintainable code and a workable exit, the partnership is moving toward sovereignty. If it offers only a platform name and a signature count, wait for the next layer of evidence.

References

• Hindu Post – Beyond broad pledges: Bharat’s tech sovereignty push in Africa and ASEAN