Zero Trust in banking: Why VPNs are no longer enough
For 25 years, financial entities have protected their systems with the same model: a network perimeter (firewalls + VPN) separating "secure internal" from "dangerous external". This model is broken.
Why the perimeter no longer works
| Factor | 2026 Reality |
|---|---|
| Hybrid cloud | Applications no longer sit in a single data center — they're on AWS, Azure, GCP and on-premise simultaneously |
| Remote work | 40-60% of staff access from outside the perimeter |
| Open APIs | PSD2, Open Banking and regulation require exposed interfaces |
| Supply chain | ICT providers access internal systems for support and operations |
| Lateral movement | Once inside the perimeter, an attacker moves freely |
The fundamental premise
Zero Trust starts from an axiom: "never trust, always verify". Whether the request comes from inside or outside the network — every access is individually verified, on every interaction.
What Zero Trust means in practice
1. Identity as perimeter
Instead of trusting the network, trust in verifiable cryptographic identity:
| Classic model | Zero Trust model |
|---|---|
| "You're on the VPN → you're trusted" | "Prove who you are with a cryptographic certificate" |
| Firewall decides who enters | Each service verifies the requester's identity |
| Shared static API key | Temporary token with minimum privileges and expiration |
2. End-to-end encryption (mTLS)
Mutual TLS ensures that both ends of a communication verify each other's identity. This is especially critical in banking, where data in transit includes transactions, PII and regulatory communications.
3. Dark Services — invisible services
The most powerful Zero Trust concept: services are not exposed to the internet. They have no public IP, don't respond to port scans, don't appear on Shodan.
| Classic service | Dark Service |
|---|---|
Exposed at api.bank.com:443 | No public IP — invisible to internet |
| Protected by WAF + firewall | No WAF needed — no attack surface |
| Vulnerable to DDoS | Immune to DDoS — no endpoint to attack |
| Scannable with Nmap | Non-existent for scanners |
Zero Trust and DORA: mandatory convergence
DORA doesn't mention "Zero Trust" explicitly, but its requirements converge directly:
| DORA Requirement | Zero Trust Implementation |
|---|---|
| ICT risk management (Art. 5-16) | Identity inventory, granular access policies |
| Operational resilience (Art. 9) | Circuit breaker, spooling, autonomous reconnection |
| Encryption (Art. 9.3.b) | End-to-end mTLS, no data in clear |
| Access control (Art. 9.4.c) | Minimum privileges, temporary tokens, four-eyes |
| Continuous monitoring (Art. 10) | Automatic alerts, immutable audit trail |
How BlueUP implements Zero Trust architecture
| Component | Technology | Function |
|---|---|---|
| Human identity | Keycloak OIDC/PKCE | Federated auth without static passwords |
| Workload identity | SPIRE SVIDs (Ed25519) | Rotating cryptographic identity per service |
| Authorization | Biscuit Tokens | Capability tokens with offline attenuation |
| Network | OpenZiti Dark Services | Services invisible to the internet |
| Encryption | End-to-end mTLS | Mutual verification on every connection |
| Policies | OPA (Open Policy Agent) | Centralized access policy evaluation |
📩 Does your entity need a Zero Trust architecture?
We'll show you how to protect your critical applications without VPN and with native DORA compliance.