The failure of the corporate VPN
Historically, Nigerian companies secured their networks by building a strong perimeter (the moat). If you were inside the office or connected via VPN, you were trusted. You could access internal servers, administrative dashboards, and databases with minimal friction.
This model is catastrophically vulnerable to social engineering. If an attacker successfully phishes a customer support agent's VPN credentials, the attacker is instantly placed "inside the castle." They can then move laterally across the flat internal network, escalating privileges and exfiltrating data.
Verify Explicitly
Zero Trust operates on the principle of "never trust, always verify." Every request, whether from outside or inside the network, must be authenticated and authorized.
Least Privilege
A user or service is only granted the minimum level of access necessary to perform a specific task, for the shortest possible duration.
Assume Breach
The architecture is designed with the assumption that the internal network is already compromised, forcing strict segmentation and monitoring.
Implementing Zero Trust in a fintech startup
Migrating a legacy bank to Zero Trust takes years. A Nigerian fintech startup building on AWS or GCP can implement it from day one with modern tooling.
1. Identity as the new perimeter
The network boundary is no longer the firewall; it is the user's identity. Implement a centralized Identity Provider (IdP) like Okta or Azure AD. Every internal application (customer support portal, Grafana dashboards, staging environments) must sit behind this IdP.
2. Context-aware access
Authentication should not rely solely on a password and OTP. Zero Trust evaluates the context of the request. The IdP should analyze:
- Device Posture: Is the request coming from a company-issued laptop managed by MDM? Is the OS patched? Is disk encryption enabled?
- Location: Is the request originating from an unusual IP address or a known Tor exit node?
- Behavior: Is the user attempting to download 10,000 KYC records at 3:00 AM on a Sunday?
3. Micro-segmentation
Zero Trust applies to machine-to-machine communication as well. As discussed in our microservices security guide, internal services must authenticate each other using Mutual TLS (mTLS). The payment service should not trust the notification service simply because they share the same Kubernetes cluster.
Building a new fintech platform? Ensure your architecture is secure by design.
Book an Architecture ReviewThe roadmap to Zero Trust
You don't achieve Zero Trust overnight. We recommend a phased approach for fintechs:
- Phase 1 (Identity): Enforce SSO and phishing-resistant MFA (Hardware Security Keys) for all staff accessing critical infrastructure.
- Phase 2 (Device): Roll out Mobile Device Management (MDM) to ensure only compliant devices can authenticate.
- Phase 3 (Network): Replace the corporate VPN with identity-aware proxies (e.g., Cloudflare Access, BeyondCorp) to broker access to internal apps on a per-request basis.
- Phase 4 (Workload): Implement a service mesh (like Istio) to enforce mTLS and micro-segmentation across your backend microservices.
Assumed Breach Pentesting
To test a Zero Trust Architecture, we conduct an "assumed breach" assessment. We start the engagement with access to a standard employee's laptop and credentials. The test evaluates whether our engineers can escalate privileges or access the Cardholder Data Environment from that compromised starting point.
Related reading
Blog: Securing Microservices · Defending Support Teams
Services: Secure Architecture Review
Frequently asked questions
{faq.q}
{faq.a}