MFA for African financial institutions: Meeting compliance requirements on-premises

Financial institutions across Africa are facing higher levels of scrutiny as regulators and insurers demand stronger authentication. For those built around Active Directory, their challenge is to implement on-prem multi-factor authentication (MFA) that can secure their existing infrastructure. UserLock adds MFA and access controls directly to on-premises Active Directory — no architectural changes, no added complexity. This article looks at why AD-based financial institutions across the continent are turning to UserLock to meet compliance requirements and lower credential-based risk.

The next decade is shaping up to be on the most challenging that African banks have ever faced. Across the continent, cybercrime is surging, encouraged by past cybersecurity under-investment. Banks are struggling to contain threats, constrained by resources, perennial skills shortages, and a lack of consistent standards and regulation.

But change is now coming. A 2025 meeting of the Alliance for Financial Inclusion (AFI), an organization formed to shape banking policy in developing countries, set out a new cybersecurity approach for African banks: drive up standards using stricter regulation, partner with leading banks from other parts of the world, and make cybersecurity a policy priority.

The message is clear: in future, banks should expect tougher compliance and a greater emphasis on cybersecurity resilience and data sovereignty. Meanwhile, the biggest weaknesses of all, the over-reliance on insecure legacy systems, will finally need serious attention.

While cloud adoption is rising, a high proportion of banks and financial institutions worldwide still rely on on-premise networks running Active Directory IAM. African banks are no exception.

Inertia explains some of this. Windows networks were once on-premise by default: a topology which has persisted. In other cases, financial institutions have good reason to stick with AD as their core IAM system over cloud alternatives such as Entra ID (formerly Azure AD). 

Why are banks still wedded to AD? The answer is a complex mixture of reasons that have nothing to do with simply not moving with the times. In many use cases, using AD as the authoritative identity store still has important advantages:

• Core applications: on-premise networks are necessary to support legacy applications that aren't compatible with cloud platforms. Many of these applications are highly specialized and re-developing them for cloud platforms is impractical. 

• Cost: budgets are limited and AD networks have already been paid for. Moving to the cloud would add cost and require the sort of new skills that are hard to acquire in many countries.

• Connectivity: cloud systems assume local hosting facilities and good connectivity, which assumes uniform access to infrastructure.

• Independence: in a growing number of African countries, banking regulation requires that banks manage core applications in-house. In some cases, the same applies to data, which emphasizes the need for institutional independence, resilience against cloud disruption, and data sovereignty.

This forces banks to run and secure two completely different types of networks: an older on-premise one used to host internal applications the banks can't operate without, and a newer cloud one that is now fundamental to hosting public web services.

Unlike cloud platforms, which feature integrated controls, securing perimeter networks built around AD is a case of do-it-yourself. This can make life difficult; AD started life in the 1990s and lacks many security controls that have since become essential. For African banks, this creates numerous security challenges:

• Group Policy Object (GPO) limitations: AD GPOs are a static control and don't enforce conditional security, for example limiting concurrent logins, defining time-based hours for network access, or applying policies to remote higher-risk connections.

  They also lack an auditing function; admins can't see how many endpoints conform to the desired security level.

• Management complexity: Over time, GPOs accumulate, creating a web of policies that conflict with one another and slow performance. Admins can find that they spend more time managing GPOs than securing users.

• Multi-Factor Authentication (MFA) gaps: AD lacks native support for MFA, and adding modern authentication requires organizations to source and configure a separate product. Microsoft's products for this add complexity and cost. The lack of native AD MFA is a particular regulatory pain points in African countries where this control is mandated for compliance reasons.

• Independence and sovereignty: Banking often requires that organizations manage their own data and IAM security. In these use cases, cloud systems such as Entra ID and Azure are not an option.

For many African banks, these issues are a recurring theme which can only be solved through third-party platforms such as UserLock.

Examples of the problems African banking sector customers have deployed UserLock to solve include:

• A private bank was struggling with GPO management and the lack of MFA security and session control in its AD estate. Limiting concurrent sessions was another concern.

• A credit institution needed MFA to meet PCI compliance requirements.

• A Finance Ministry wanted to secure its AD network with MFA to meet modern security standards while keeping their IAM on premises.

UserLock addresses these challenges by bridging the gap between AD's IAM and security limitations and modern security requirements without forcing organizations into the cloud.

Designed as a direct overlay on top of AD, UserLock adds modern access security capabilities such as concurrent session control, contextual network controls, and full-featured MFA. Importantly, organizations gain real-time visibility on how their user base is interacting with AD at any moment in time.