MESOB and Fayda: security becomes central when 185 Ethiopian services share one doorway

A new front door for government

Ethiopia launched the MESOB platform on 20 June 2026 to centralise access to more than 185 public services, according to reporting by We Are Tech Africa. The application relies on Fayda, the national digital identity system, and is intended to connect several government databases. Announced services include identity documents, tax procedures, business licences, work permits and investment formalities.

The project addresses a real problem. Citizens and businesses often submit the same information repeatedly to agencies that exchange little data. A shared account and controlled data exchange can reduce travel, accelerate applications and make processes more traceable.

Security changes scale when previously separate services begin to share identity, interfaces and technical dependencies. MESOB is not simply another application. It can become a concentration point for access to digital public services. Concentration is not a reason to reject the model, but it requires architecture and governance proportionate to its importance.

Digital identity becomes the first perimeter

When Fayda is the common access key, compromise of one account may extend beyond one service. An attacker who steals credentials, abuses recovery or manipulates enrolment could try to perform several procedures through the same identity. Protection must therefore cover the full lifecycle: registration, identity proofing, authentication, recovery, phone changes, revocation and death records.

Authentication strength should follow risk. Reading general information does not require the same assurance as changing a register, obtaining an official document or authorising a financial action. MESOB should require step-up authentication for sensitive operations instead of treating every session equally.

A phone is convenient but should not become the only evidence of identity. SIM loss, number reassignment, SIM swap, limited coverage or disability can exclude a legitimate user or create a fraud path. Alternative recovery methods are still necessary, but they must be controlled, documented and logged.

APIs become critical infrastructure

A unified platform does not necessarily copy all government information into one database. It may orchestrate requests to ministries and agencies. In that model, APIs become the essential security boundary. Broken authorisation can let one service read more data than intended. Predictable identifiers can expose another citizen's record. A faulty integration can propagate errors across agencies.

Every API should have an owner, a data inventory, a documented purpose and a retention policy. Authorisation must be evaluated on the server for every request, not only in the user interface. Technical secrets must be rotatable and stored outside source code. Abnormal volumes, repeated requests and cross-agency access need to be observable.

Data minimisation is particularly important. The existence of information in one agency does not mean every MESOB service should be able to retrieve it. Exchanges should provide only what a transaction needs, supported by clear consent or a defined legal basis.

Availability and systemic risk

Centralisation improves experience when the platform works. It can amplify failure when it does not. An authentication, DNS, connectivity or cloud-provider outage could prevent several agencies from serving people at the same time. A denial-of-service attack could consequently have broader public impact than an attack against one ministry portal.

MESOB needs explicit recovery objectives, redundant dependencies and degraded operating modes. Some transactions can continue offline or enter a queue; others require real-time verification. Those decisions must be made before an incident. Agencies also need a trusted communication process so they can confirm outages without driving users toward fraudulent replacement links.

Logging without building a surveillance system

Logs are essential for fraud detection and investigation: login attempts, profile changes, sensitive record views, API calls, authorisation decisions and administrative actions. Yet a central log of a citizen's interactions can itself become an exceptionally sensitive dataset.

Governance must limit who can search those records, for how long and for which purposes. Administrator activity should be logged and reviewed. Security teams need useful signals, but not necessarily the full content of every case file. Pseudonymisation, role separation and differentiated retention can reduce exposure.

Transparency is also a security control. A user should be able to see which agencies accessed important information, report an unfamiliar action and correct inaccurate data. That capability supports trust and turns citizens into an additional source of detection.

What the launch should trigger

• Publish a responsibility model for MESOB, Fayda and connected agencies.
• Commission independent tests of enrolment, account recovery and APIs.
• Apply adaptive authentication to high-impact transactions.
• Define degraded modes and run outage exercises across ministries.
• Give citizens a history of important actions and a dispute channel.
• Publish useful post-incident information without exposing personal data.

A wider lesson for African digital public infrastructure

Several African states are building digital public infrastructure around identity, payments and data exchange. MESOB demonstrates the intended benefit: government services that are easier to reach through one account. It also shows why cybersecurity cannot be added after launch.

Success should not be measured only by the number of connected services. It should include safe account-recovery rates, real availability, revocation time, inventoried APIs, detection speed and citizens' ability to understand how their data is used. A unified platform becomes credible when its security is as integrated as its interface.

— ◆ —