Why USSD banking services in Rwanda need security testing

In East Africa, USSD is not legacy technology. It is critical infrastructure. Millions of people across Rwanda, Uganda, Kenya, and Tanzania rely on *182# and similar short codes for banking, mobile money, and payments every day. USSD works on any phone, requires no internet, and reaches populations that smartphones and banking apps cannot.

Yet USSD applications are among the most under-tested systems we encounter in security engagements. They sit behind telecom gateways, often overlooked in security assessments that focus on web and mobile apps.

Why USSD is a security target

USSD services handle real money and real data. A typical USSD banking session involves authentication, account balance checks, fund transfers, bill payments, and airtime purchases. A vulnerability in any of these flows can lead to financial loss and regulatory consequences.

Unlike web applications that benefit from decades of security tooling and research, USSD has a smaller security community and fewer off-the-shelf testing tools. This creates a false sense of security for many organisations.

Common USSD vulnerabilities

From our experience testing USSD platforms for financial institutions, these are the vulnerability categories we find most often:

Session management flaws

USSD sessions are inherently stateless at the protocol level, so the application layer must manage state. We frequently find session tokens that are predictable, sessions that do not expire properly, or sessions that can be hijacked by manipulating parameters at the gateway level.

Authentication bypasses

USSD services often authenticate users by MSISDN (phone number) passed from the telecom gateway. If the application trusts this value without additional verification, an attacker with access to the gateway or API layer can impersonate any customer by simply changing the MSISDN parameter.

Insecure API backends

USSD front-ends typically communicate with backend APIs (often the same APIs used by mobile banking apps). We test both the USSD-specific gateway interface and the underlying API to find issues like missing authorisation checks, IDOR vulnerabilities, and data exposure.

Input validation failures

USSD menus accept numeric input, but the backend processing may be vulnerable to injection attacks if input is not properly sanitised before being passed to databases or downstream systems.

PIN handling weaknesses

How the USSD application handles PINs is critical. We look for PINs transmitted in cleartext, PINs logged in application logs, lack of brute-force protection, and PINs that are not properly hashed at rest.

Our USSD testing methodology

Testing USSD services requires a different approach than standard web application testing. Our methodology covers:

• Gateway interface testing: intercepting and manipulating USSD requests at the telecom gateway integration point
• Session analysis: mapping how sessions are created, maintained, and destroyed
• Authentication testing: verifying that MSISDN validation cannot be bypassed
• Authorisation testing: ensuring users can only access their own accounts and transactions
• Backend API testing: full assessment of the APIs that power USSD menus
• PIN and credential handling: verifying secure storage, transmission, and brute-force protection
• Business logic testing: attempting to manipulate transaction flows, bypass limits, or exploit race conditions

For regulators and compliance teams

If your institution offers USSD banking services and needs to demonstrate BNR compliance, your penetration testing scope should explicitly include USSD. A web-only assessment leaves a critical attack surface untested.

When requesting proposals from security firms, ask specifically whether they have experience testing USSD platforms and what their methodology covers. Not all penetration testing providers have the expertise to test these systems effectively.

USSD testing should be part of your broader VAPT programme. For BNR-regulated institutions, our BNR compliance guide explains the full requirements. See our pricing guide for what to expect cost-wise.