Okta deployments fail in predictable ways. Not because Okta is a difficult product — it is one of the more thoughtful platforms I work with — but because identity governance is a set of decisions that look technical and are actually organisational. Decide them badly, and the platform that was supposed to simplify access becomes an expensive login page that sits in front of a mess.
Libertad became an Okta Partner earlier this year. Before that, I spent the preceding decade configuring, replacing, and occasionally rescuing identity platforms — Okta, Azure AD, Ping, and earlier on-premise systems that should stay in the ground. This is a note on the five failure modes I keep seeing when fintechs and financial services firms in Sub-Saharan Africa deploy Okta, and how to avoid them.
The scale is deliberately the 50-to-300-employee band. Larger institutions have different problems. Smaller ones usually have not yet reached the point where Okta is the right answer.
Failure mode 1: No clear source of truth for identity
Every Okta deployment has to answer one question on day one: where does a new employee exist first?
The good answer is the HRIS. Workday, BambooHR, Sage People, SimplePay — whichever system the HR team actually uses. A new hire is created there, Okta provisions accounts downstream, and the chain is clean.
The bad answer — and the one I see most often — is that nobody decides. Finance creates the person in the payroll system. IT creates the account in Microsoft 365. HR creates the record in whatever tool they use. Okta gets plugged in later and ends up as a downstream consumer of whichever of those three happens to get integrated first. The identity record is now ambiguous.
Once a deployment ships without a clear source of truth, the joiner–mover–leaver process becomes negotiable. Different apps get provisioned on different timelines. Offboarding becomes a set of manual steps rather than a single event. The cost compounds every quarter.
**Fix:** Before the first Okta integration is built, name the source of truth in writing, and have the CTO and Head of People both sign off. This is a thirty-minute conversation that saves the deployment.
Failure mode 2: Directory silos masquerading as “hybrid
Most African fintechs I work with are running some combination of Microsoft 365 and Google Workspace. Sometimes Slack. Often a handful of SaaS tools acquired by different teams at different times, each with its own user directory.
The fintech decides to deploy Okta. The engineering lead says “let’s integrate M365 first.” The operations lead says “Google Workspace is where most of our data lives, let’s start there.” A decision gets made, Okta gets connected to one, and the other continues to operate as a separate identity store. Six months in, nobody is sure which directory is authoritative for what.
The technical term for this is an identity silo. The practical term is “your deprovisioning process has three holes in it.”
**Fix:** If you are deploying Okta as the central identity platform, both M365 and Google Workspace need to be brought in as *managed apps*, with Okta as the source of authentication and — where possible — the lifecycle manager. The integrations exist. They work. The failure is usually in not prioritising the unglamorous directory that the original champion did not think about.
Failure mode 3: MFA is enrolled, but MFA is not enforced
Okta’s MFA capability is strong. Push notifications, FIDO2 security keys, phishing-resistant factors — all well-supported. The failure is rarely in the platform. The failure is in the policy.
What I see: the organisation deploys Okta, enrols all users in MFA, and then writes a single policy that says *”require MFA on sign-in.”* The CISO presents this to the board. The board is satisfied.
What is actually happening: the policy has exceptions. Service accounts are exempted. The CEO has an exception because they travel and the friction is too high. The finance team has an exception because an integration broke when MFA was enforced and nobody has had time to fix it. The contractor onboarding flow skips MFA for the first 30 days because of a quirk in how they are provisioned.
Each exception was defensible when it was granted. The composite is an MFA posture with holes in it, and the attacker only needs to find one.
**Fix:** Audit the exceptions list quarterly. Document the justification for each one. Set an expiry date. If an exception has lasted more than six months without being revisited, it is no longer an exception, it is policy — and the policy is that MFA is optional for some of your people.
The secondary fix is to move toward phishing-resistant factors (WebAuthn, security keys) for privileged users. SMS and push-based MFA are bypassable with current credential-phishing kits. The attackers know this. Your controls should too.
Failure mode 4: Groups as static lists instead of attributes
Okta’s power comes from attribute-based group membership. You can define a group as *”everyone in the Finance department who is a permanent employee and based in the Cape Town office”* and that group populates itself, updates itself, and empties itself when people change roles or leave.
The failure is to not use this. Instead, the deployment treats Okta groups the way it treated Active Directory groups in 2012 — as static lists that someone manually maintains.
The symptom is easy to spot. The “Finance” group has 17 members, 14 of whom are in finance, 2 who moved to operations six months ago, and 1 who resigned in January. Somebody needs to clean the group up. Nobody is assigned to do it. The group was a manual artefact from day one.
**Fix:** Define groups by attribute wherever possible. Source the attributes from the HRIS. A group that defines itself does not need cleaning up, because the definition moves with the person. This is the core discipline of identity governance at scale, and the reason Okta exists in the first place.
A practical test: if removing a person from a group is a manual step, your group model is the problem.
Failure mode 5: SCIM not configured, or configured on the wrong apps
SCIM is the protocol that allows Okta to create, update, and — critically — delete user accounts in downstream apps automatically. When SCIM is working correctly, offboarding a user in the HRIS cascades through the organisation in minutes, not days.
When SCIM is not configured, offboarding is a ticket. The ticket goes to someone’s queue. The queue has a backlog. The person who left on Friday still has access to GitHub, AWS, the design tool, and the customer database on Wednesday.
The common mistake is to configure SCIM on the flashy apps — M365, Google, Slack — and not on the apps where a departing employee can actually cause harm. GitHub. AWS. The production database tool. The cloud cost management platform. Critical customer-facing admin tools.
**Fix:** Inventory your apps by the blast radius of a departing employee with active access. Prioritise SCIM configuration by blast radius, not by how many users the app has. The CRM with 150 users matters less than the production database console with three.
This is also the single most defensible control for Joint Standard 2 compliance on identity, and the one I spend most time on in remediation work. The Standard requires that access is limited to authorised users and devices. An automated, auditable offboarding flow is the cleanest way to demonstrate that control.
A note on what Okta is not
Okta is not a substitute for a coherent identity strategy. It is the engine that executes the strategy. If the strategy is unclear — no source of truth, no group model, no lifecycle ownership — the best identity platform in the world will not save you, and any other platform you choose will fail in the same ways.
For fintechs operating in environments like South Africa’s post-JS2 compliance regime, Kenya’s Data Protection Act, or Nigeria’s NDPR, the question is not *”which identity platform should we buy?”* It is *”what does our joiner–mover–leaver process need to prove, and what tooling supports that?”*
If the answer to the second question is Okta, the five failure modes above are the ones I would put on the project’s risk register before writing the first integration. They are what separate deployments that hold up under audit from deployments that look good in the demo and leak quietly for the next two years.
