Kenya has opened talks with French secure identity provider IN Groupe to build a national digital identity authentication platform that would let citizens access government and private sector services through a single, verified digital identity. The discussions, held between ICT and the Digital Economy Cabinet Secretary William Kabogo Gitau and an IN Groupe delegation led by Celine Gouveia, the company's Vice President for Sales and Business Development in Government Programs, mark the clearest signal yet that the ministry wants to consolidate Kenya's fragmented identity infrastructure under one authentication layer.According to Kabogo, the proposed platform is designed to reduce repeated identity verification and cut down on the unnecessary submission of personal information whenever citizens interact with different services. The two sides agreed to deepen technical and policy collaboration toward what both described as a trusted and interoperable digital identity ecosystem for the country.<ad-spot></ad-spot>The talks come at a delicate moment. Kenya's last two attempts at building a national digital identity system, Huduma Namba and its successor Maisha Namba, have both landed in court, both been accused of inadequate privacy safeguards, and both remain unresolved years after launch. Any new authentication layer will be built on top of that unfinished business, not instead of it.<h2>What Was Actually Discussed</h2>The core proposal is an authentication platform, not a new identity register. Kenya already has multiple identity touchpoints: the National Registration Bureau's ID database, the Maisha Namba ecosystem's Unique Personal Identifier and Digital ID, biometric passport records, and a scatter of sector-specific verification systems run by banks, telcos, and government agencies through eCitizen and other portals. What Kabogo and the IN Groupe delegation discussed was a layer that sits above these systems, letting a citizen prove who they are once and have that proof recognised across public and private services without resubmitting documents or biometric data each time.The discussions also touched on governance. Kabogo indicated that while individual ministries and agencies would continue to run their own services, his ministry should provide overarching coordination to keep the identity ecosystem consistent across government. That is a notable admission on its own: it implies the current setup, where different arms of government run overlapping identity and verification systems with little central coordination, is part of the problem the new platform is meant to fix.<ad-spot></ad-spot>No contract, procurement timeline, or financial figure has been disclosed. What exists so far is a statement of intent to collaborate on both the technical architecture and the policy framework needed to support it.<h2>Who IN Groupe Is</h2>IN Groupe is not a new entrant to government identity work. The company traces its lineage to France's Imprimerie Nationale, the state printing house founded in 1538, and rebranded as IN Groupe in 2018 to reflect a broader mandate covering physical identity documents, biometric systems, and public key infrastructure. The company maintains partnerships with roughly 30 governments worldwide, with products and services deployed across 130 countries, and already operates a commercial office in Kenya alongside others in the United Arab Emirates, Malaysia, Singapore and India. Exports accounted for more than 55 percent of its 2023 revenue, underlining how central government contracts outside France have become to its business.On the continent, IN Groupe's track record is mostly in physical document production rather than large-scale digital identity platforms. Its passport booklet references include Gabon, Ivory Coast, Benin, Djibouti, Senegal and Seychelles, and it recently won a tender to produce Seychelles' new biometric passports and issuing system, building on a relationship with that government stretching back more than two decades. The company also markets IN Wallet, a digital platform for storing government-issued credentials, which is closer in concept to what Kenya is now discussing than its passport-printing heritage.<ad-spot></ad-spot>IN Groupe is entering a market already served by established rivals. Idemia, born from the 2017 merger of Safran, Morpho and Oberthur Technologies, is present in 25 African countries and manages the continent's largest biometric database in Nigeria, while Belgium's Semlex has built a controversial footprint issuing national identity documents in several African states, including a large Ivory Coast contract, amid persistent allegations over how those contracts were won. Kenya's decision to talk to IN Groupe rather than deepen ties with an incumbent vendor suggests the ministry is treating this as an open field rather than a renewal of an existing relationship, though it has not said whether a competitive procurement process will follow.<h2>The Weight of Huduma Namba and Maisha Namba</h2>Kenya's history with centralised digital identity is the backdrop every stakeholder will read this announcement against. The government first attempted a unified identity system in 2018 under Huduma Namba, which established the National Integrated Identity Management System, a centralised database intended to consolidate government records on every citizen. In 2020, the High Court of Kenya acknowledged concerns raised by digital rights groups, including risks of data breaches, exclusion and discrimination, and suspended the rollout until the government addressed them. That suspension effectively ended Huduma Namba as originally designed.In November 2023, the government launched Maisha Namba as its replacement, built around a Unique Personal Identification number and Digital ID alongside a redesigned physical card. The new system fared little better in the courts. The following month, Haki na Sheria Initiative filed a petition against the government challenging the rollout, arguing it violated the constitutional right to privacy and risked discriminating against marginalised communities, with the Katiba Institute filing a separate case on related grounds. The High Court blocked the rollout for lack of a Data Protection Impact Assessment, a decision commentators noted echoed the ruling that had effectively ended Huduma Namba years earlier.The litigation has continued in phases since. Lawyers for Haki na Sheria argued in court in July 2024 that privacy could not be guaranteed because the Maisha ecosystem would be accessible to private firms not necessarily offering government services, and raised concern that the ten-year expiry on the citizenship document could leave people unable to renew it classified as aliens in their own country. Petitioners also told the court that Maisha Namba data was set to be shared with 450 entities, a figure that has become a reference point in subsequent public debate about the system's data-sharing scope. Expert witnesses, including a Privacy International researcher, testified that the ID system's centralised data repository could potentially function as a surveillance tool.The government has continued to push the project forward regardless. Officials cleared a backlog of more than 600,000 ID cards in 2024 and continued issuing Maisha Cards to new applicants, with Immigration Principal Secretary Julius Bitok stating the new system would rely on existing biometric data rather than require the mandatory re-registration that undermined Huduma Namba. The government has budgeted roughly KES 6.88 billion for the 2024/2025 fiscal year on digital IDs, passports and birth certificates, on top of earlier allocations. A court order was lifted in August 2024 to avoid halting essential ID services, but the underlying constitutional questions remain unresolved before the courts.This is the environment into which IN Groupe's proposed authentication platform would be introduced. An authentication layer that sits above Maisha Namba's identity register does not resolve the pending litigation over that register's constitutionality, its data-sharing scope, or its treatment of marginalised communities. If anything, adding a new layer of interoperability across government and private services raises the stakes of getting the underlying data protection questions right, since a breach or overreach at the authentication layer would now touch more systems at once rather than one at a time.<h2>What an Authentication Layer Would Need to Get Right</h2>Three technical and governance questions will determine whether this initiative fares better than its predecessors.The first is data minimisation in practice, not just in messaging. Kabogo's framing, that the platform should reduce unnecessary submission of personal information, is the correct design principle: a well-built authentication system verifies a claim (this person is over 18, this person is a licensed driver) without necessarily exposing the underlying record every time. Whether IN Groupe's proposed architecture actually implements selective disclosure of this kind, or simply centralises access to fuller identity records behind a single sign-on, will only become clear once technical specifications are public. The Maisha Namba litigation exists precisely because petitioners argued the opposite happened in practice: broad data sharing dressed up as convenience.<ad-spot></ad-spot>The second is interoperability governance. Kabogo's comment that his ministry should coordinate across agencies while each retains control of its own services describes a federated model, which is generally the safer design choice for a country with Kenya's litigation history, since it avoids concentrating all citizen data in one database. But federation only works if there is a binding data-sharing agreement and independent oversight of what gets requested and logged at the authentication layer. Kenya's Office of the Data Protection Commissioner would need a clearly defined role in auditing this system from the design stage, not after deployment, given that the absence of a completed Data Protection Impact Assessment was the specific defect that twice halted prior rollouts.The third is vendor dependency. IN Groupe's African track record is concentrated in physical document production and passport issuing systems rather than large national authentication platforms of the kind now being discussed. That does not disqualify the company, but it does mean Kenya would be an early reference case for IN Groupe's digital identity ambitions in East Africa, which cuts both ways: the vendor has commercial incentive to make the deployment a showcase, but Kenya would also carry more of the integration risk than it would with a vendor whose authentication platform has already been proven at similar scale elsewhere. Contract terms on data localisation, source code or architecture escrow, and exit provisions would matter more here than in a straightforward document-printing tender.<h2>Where This Leaves the Timeline</h2>No procurement process, budget line, or implementation date has been announced. The talks described so far are exploratory, focused on technical and policy alignment rather than a signed agreement. Given that Maisha Namba's core litigation is still active in the High Court, any authentication platform that depends on the Maisha Namba identity register as its underlying source of truth is, for now, being built on a foundation whose legal status is not fully settled.For a ministry that has in the past year also lent its endorsement to a privately developed cryptocurrency token with only a loose connection to government digital economy policy, the IN Groupe talks represent a more conventional and arguably more consequential piece of digital public infrastructure. Whether it fares better than Huduma Namba and Maisha Namba will depend less on which vendor Kenya chooses and more on whether the data protection groundwork that was missing the first two times gets done before, rather than after, deployment begins.

Kenya Turns to France's IN Groupe for a Unified Digital Identity Platform, But the Trust Deficit Remains

If you are a Kenyan or African developer building on Cloudflare R2, there is a feature that quietly launched in open beta earlier this month that you should enable on your buckets right now. It is called Local Uploads, it costs nothing extra, and depending on where your users are relative to your bucket, it could cut your upload latency by up to 75%.That is not a marketing number. It is from Cloudflare's own synthetic benchmarks, and the underlying reason it matters so much for African developers specifically is worth understanding.<h2>The Problem: Your Bucket Is Far Away</h2>When you create an R2 bucket, it lives in a specific region — typically somewhere in the US or Europe, because those are where the primary storage locations are. Your Cloudflare Workers run at the edge, close to your users, which is why reads are already fast globally. R2 automatically caches reads across Cloudflare's network.But writes have always been a different story.When a user in Nairobi uploads a file to your app — a profile picture, a document, a video clip — that data has to travel all the way from their device to your bucket's physical location. If your bucket is in Eastern Europe, you are looking at a round trip that crosses oceans and multiple network hops. The result is slow, variable, and sometimes unreliable upload performance.<img src="https://cdn.calebms.com/articles/64284af2-9b99-4748-b401-54a6906941be.png" alt="49662.png">This is the "distance problem," and it has been the one area where R2's promise of global performance broke down. Until now.<h2>What Local Uploads Does</h2>Cloudflare's Local Uploads feature changes how R2 handles write requests when the client is in a different region from the bucket.Here is what happens with Local Uploads enabled:1. Your user in Nairobi initiates an upload.2. R2 receives the request at the nearest Cloudflare point of presence — in this case, likely the Nairobi or Mombasa data centre.3. The object data is written to storage infrastructure close to the user immediately.4. R2 returns a success response to the client right away. The upload is done from the user's perspective.5. In the background, Cloudflare replicates the data to your bucket's home region asynchronously.The critical detail is step 4. The object is immediately accessible and strongly consistent the moment the upload completes — there is no waiting for replication to finish before the file can be read. Cloudflare handles the background copying with automatic retries to ensure nothing is lost.<img src="https://cdn.calebms.com/articles/167b84e8-0b15-4f06-8b32-248d7f15fa4e.png" alt="49663.png">In Cloudflare's own benchmark tests — simulating a client in Western North America uploading to a bucket with an Asia-Pacific location hint — median upload time dropped from around 2 seconds to around 500 milliseconds after enabling Local Uploads. That is a 75% reduction in Time to Last Byte.<img src="https://cdn.calebms.com/articles/708d1177-2574-4dfb-8c75-d9663dbc6af8.png" alt="49661.png">For a user in Nairobi uploading to a US-based bucket, the distance and latency profile is even more extreme than that benchmark scenario. The gains are likely to be at least as significant, and possibly more.<h2>Why This Matters More for Africa Than Almost Anywhere Else</h2>Cloudflare has over 300 points of presence globally, including multiple locations across Africa — Nairobi, Lagos, Johannesburg, Cairo, and others. This means the "nearest PoP" for your Kenyan users is genuinely nearby, not a European proxy.But the primary R2 storage regions are concentrated in North America, Europe, and Asia-Pacific. There is no R2 storage region in Africa. This means every single upload from an African user to an R2 bucket — without Local Uploads — has been making a cross-continental journey.That gap matters in practical terms. If you are building:<ul class="tight" data-tight="true"><li>A file sharing or document management app with Kenyan users</li><li>A media platform where users upload photos or videos</li><li>A mobile app that syncs data or logs to R2</li><li>An e-commerce platform where sellers upload product images</li></ul>...every upload your users make has been traveling thousands of kilometres more than it needed to. Local Uploads eliminates that penalty.<h2>One Thing to Know Before You Enable It</h2>Local Uploads works best when your reads and writes come from the same region. There is a nuance worth understanding: when a file is uploaded locally and replication to the home bucket region is still in progress, a read request coming from near the bucket's home region — not from near the uploader — may experience some latency until replication completes.In practice, for most Kenyan and African developer use cases, this is not a concern. If your users are uploading and reading their own content from the same general region, the experience is fast in both directions. The edge case to watch is if you have a backend process in the US reading files immediately after an African user uploads them — there could be a brief window before replication completes.Also worth noting: Local Uploads is not available for buckets with jurisdictional restrictions enabled, such as EU-restricted or FedRAMP buckets, because the feature requires temporarily routing data through locations outside the bucket's designated region.<h2>How to Enable It</h2>Enabling Local Uploads takes about 30 seconds and requires no code changes. It works with the S3 API, Workers Bindings, and plain HTTP — whatever you are already using continues to work exactly as before, just faster.Via the Cloudflare Dashboard:1. Log in to the Cloudflare dashboard.2. Navigate to R2 Overview.3. Select the bucket you want to update.4. Go to the Settings tab.5. Find Local Uploads and select Enable.That is it. Existing uploads complete normally with no interruption to traffic.Via Wrangler (CLI):If you prefer the command line, a single command does the job:<pre><code>npx wrangler r2 bucket local-uploads enable [YOUR_BUCKET_NAME]</code></pre>Replace `[YOUR_BUCKET_NAME]` with the name of your bucket. You can also disable it at any time with:<pre><code>npx wrangler r2 bucket local-uploads disable [YOUR_BUCKET_NAME]</code></pre>Cost: There is no additional cost. Upload requests incur the standard Class A operation costs, exactly as they did before Local Uploads.<h2>How to Verify It Is Working</h2>Once enabled, you can monitor the impact through the R2 bucket metrics page in the Cloudflare dashboard. Navigate to your bucket, select Metrics, and look at the Request Distribution by Region chart. This shows you the geographic distribution of read and write requests and gives you a picture of where your traffic is coming from relative to your bucket location.<img src="https://cdn.calebms.com/articles/7f3ef8ae-0d75-406f-99ff-a4ab274e1c13.png" alt="49664.png">If you want to test it directly, Cloudflare has a public demo at <a target="_blank" rel="noopener noreferrer nofollow" href="https://local-uploads.r2-demo.workers.dev">`local-uploads.r2-demo.workers.dev`</a> that lets you simulate uploads from different geographic locations and see the latency difference with and without Local Uploads enabled.<h2>How Does This Compare to AWS S3 Transfer Acceleration?</h2>AWS offers a similar feature for S3 called Transfer Acceleration, which uses CloudFront edge locations to speed up uploads from distant clients. The approaches are architecturally different: S3 Transfer Acceleration optimises routing through the AWS network backbone, while R2 Local Uploads performs actual local writes with asynchronous replication.The practical difference for Kenyan developers is cost. S3 Transfer Acceleration carries an additional per-GB charge on top of standard S3 pricing. R2 Local Uploads is free, and R2 already has no egress fees — which is the reason many developers in Kenya and across Africa have been moving away from S3 to R2 in the first place.Google Cloud Storage and Azure Blob Storage currently have no equivalent feature that accepts local writes globally.<h2>The Bigger Picture</h2>This is the second significant developer-focused update from Cloudflare in recent weeks that has direct implications for African developers. We covered <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.techinkenya.com/articles/cloudflare-introduces-markdown-for-ai-agents-a-quiet-revolution-with-major">Cloudflare's Markdown endpoint for AI agents </a>this month — a feature that changes how AI systems consume web content, with meaningful implications for publishers on the continent.Local Uploads is a more targeted, infrastructure-level improvement, but it addresses one of the most persistent friction points for developers building user-facing applications in markets far from where cloud storage infrastructure is concentrated. The fact that it costs nothing to enable makes the decision simple.If you are building on R2, turn it on today.Are you building on Cloudflare R2? Share what you are working on in the comments — we are always looking to feature interesting projects from Kenyan and African developers.

Cloudflare Just Made R2 Significantly Faster for African Developers — Here Is What Changed and Why It Matters

In our last article, we discussed how the global AI boom is making RAM a luxury. With budget phones in Kenya likely to stick with 4GB or 6GB of physical memory for the foreseeable future, the "lazy" days of development are over.As developers, we can no longer assume the user has "infinite" resources. If your React bundle is 5MB or your Flutter app leaks memory, it won't just be slow—it will be unusable. Here is how we build high-performance apps for the Kenyan market in 2026.<h2>1. The "RAM Budget" Mindset</h2>Stop treating RAM as an unlimited pool. Start treating it like a data bundle.<ul><li>The Rule of 100MB: Aim for your app to never exceed 100MB of active heap memory on a budget device.</li><li>Kill the "Dependency Pile": Every npm install or pub add brings hidden weight. Before adding a library for a simple task (like date formatting), ask yourself: "Can I write this in 10 lines of vanilla code?"</li></ul><ad-spot></ad-spot><h2>2. Web Optimization: The JS/TS Diet</h2>For web developers, the browser is the biggest RAM hog. Chrome on a 4GB Android phone is a dangerous environment.<ul><li>Code Splitting is Mandatory: Don't ship your entire app at once. Use dynamic imports (import()) to load features only when the user clicks them.</li><li>The Image Evolution: Stop using JPEGs. Use WebP or AVIF. Use Responsive Images (srcset) to ensure a phone doesn't download a 4K image just to display it on a 720p screen.</li></ul><ul><li>Tree Shaking: Ensure your build pipeline (Vite, Webpack, etc.) is aggressively removing unused code from your production bundles.</li></ul><h2>3. Mobile Optimization: Flutter &amp; Native</h2>If you are building mobile apps, memory leaks are your biggest enemy on low-RAM devices.<ol><li>ListView.builder is Your Friend: Never use a standard Column or ListView for long lists. It renders every item at once, eating RAM. Use .builder to ensure only the visible items exist in memory.</li><li>Dispose Everything: In Flutter or Android Native, failing to call .dispose() on controllers (Animation, Scroll, Text) is the #1 reason apps crash on 4GB phones.</li><li>Asset Management: Don't bundle 20MB of 4K assets in your APK. Use on-demand delivery or host heavy assets on a CDN (like Cloudflare) to keep the initial install size tiny.</li></ol><ad-spot></ad-spot><h2>4. Code Example: Efficient List Rendering (TS/React)</h2>Instead of loading 1000 items into the DOM, use "Windowing" oir "Virtualization."<pre><code>// Good: Only renders what the user sees
import { FixedSizeList as List } from 'react-window';
 const MyList = ({ items }) =&gt; (
 &lt;List
 height={500}
 itemCount={items.length}
 itemSize={35}
 width={300}
 &gt;
 {({ index, style }) =&gt; (
 &lt;div style={style}&gt;Item {items[index].name}&lt;/div&gt;
 )}
 &lt;/List&gt;
);
</code></pre><h2>5.Testing on "Real" Kenyan Hardware</h2>Don't just test on your high-end development laptop or a $1,000 iPhone.<ul><li>The "Luthuli Test": Buy a cheap 12,000 KES phone with 4GB of RAM and 64GB of storage.</li><li>Use Profilers: Use the Android Studio Profiler or Chrome DevTools Memory tab. If you see a "sawtooth" pattern in your memory graph, you have a leak that will kill a budget phone in minutes.</li></ul><h2>Conclusion: Performance is a Feature</h2>In Kenya, performance isn't just about speed; it's about accessibility. When you optimize your app to use less RAM, you aren't just making it faster—you are ensuring that the student in a hostel or the small business owner in town can actually use your service without their phone crashing.Building "lightweight" is the new mark of a senior developer. Let's build for the hardware people actually have, not the hardware we wish they had.

Kenya Turns to France's IN Groupe for a Unified Digital Identity Platform, But the Trust Deficit Remains

Cloudflare Just Made R2 Significantly Faster for African Developers — Here Is What Changed and Why It Matters

Kenya's 4GB RAM reality: How to build lightweight apps