“Trust, but verify” was the mantra of enterprise security for a long time. In 2026, it’s not enough. Modern banking infrastructure operates on the principle of never trust, always verify — every request, every user, every microservice authenticates and authorizes itself, regardless of where it comes from. Here’s how we implemented it for a client in the Czech banking sector.

Why the Perimeter Doesn’t Work in Banking¶

The traditional network security model rests on a simple assumption: everything inside the corporate network is trusted, everything outside is a threat. Firewall at the border, VPN for remote access, done. This model made sense when applications ran on physical servers in a single data center.

Today, banking infrastructure looks different. Microservices distributed across on-premise and cloud. Third parties connected via API per PSD2. Employees working from anywhere. Containers that live for minutes. In this environment, the perimeter doesn’t exist — or more precisely, the perimeter is everywhere.

When a Czech banking institution approached us with a request to redesign their security architecture, the main driver wasn’t just security. It was DORA (Digital Operational Resilience Act), which since January 2025 requires financial institutions to demonstrate resilience of the entire ICT stack — including third-party providers. And the traditional perimeter model simply can’t do that.

Five Principles of Zero Trust¶

Zero Trust is not a product you buy. It’s an architectural approach that permeates the entire stack. We implemented it on five principles.

Verify Explicitly¶

Every access is verified based on identity, device, location, behavior, and additional context. No implicit trust.

Least Privilege¶

Every user and service has only the minimum privileges necessary for their function. Just-in-time and just-enough access.

Assume Breach¶

The architecture assumes the attacker is already inside. We minimize blast radius through segmentation and monitoring.

Micro-segmentation¶

The network is divided into isolated segments. An attacker’s lateral movement is limited even if they penetrate one segment.

The fifth principle, often overlooked: continuous monitoring and validation. Authentication is not a one-time event. Sessions are continuously revalidated based on a risk score that changes in real time according to user behavior and device state.

Architecture: Identity-Based Access and Service Mesh¶

At the core of the entire implementation is the shift from network-based access control to identity-based access control. It doesn’t matter what network you’re coming from. What matters is who you are, what permissions you have, and what the context of your request is.

Identity Provider and Contextual Authorization¶

We deployed a central Identity Provider (IdP) built on OpenID Connect, serving as the single source of truth for user and service identities. Every request carries a JWT token with claims that include not just identity but also context: device type, geo-location, risk score, and permission scope.

Authorization decisions are made by the Policy Decision Point (PDP) in real time. Policies are defined in OPA (Open Policy Agent) and version-controlled in Git — every change goes through code review and an audit trail. No policy changes ad hoc.

`# OPA Policy — example authorization for payment API

package banking.payments

default allow = false

allow {

input.method == "POST"

input.path == "/api/v1/payments"

input.user.role == "payment_officer"

input.user.mfa_verified == true

input.risk_score < 0.7

input.amount <= input.user.approval_limit

}

High-value transactions require dual approval¶

allow {

input.method == "POST"

input.path == "/api/v1/payments"

input.amount > input.user.approval_limit

input.dual_approval == true

input.approver.role == "senior_officer"

}`

mTLS and Service Mesh¶

All communication between microservices runs over mTLS (mutual TLS). Each service has its own X.509 certificate issued by an internal CA, rotated automatically every 24 hours. This is not optional — a service without a valid certificate simply cannot communicate with others.

As the service mesh, we chose Istio with Envoy proxy. The Envoy sidecar on each pod handles mTLS termination, L7 authorization, rate limiting, and telemetry — transparently, without changes to application code. For developers, nothing changes: they call HTTP endpoints as before. But under the hood, every call is encrypted, authenticated, and authorized.

Micro-Segmentation in Practice¶

Micro-segmentation is the heart of Zero Trust. Instead of flat networks where every server can see every other, we create isolated security zones with explicit rules for communication between them.

In the banking environment, we defined these segments:

• DMZ / API Gateway zone: Publicly accessible endpoints, WAF, rate limiting
• Application zone: Business logic microservices, accessible only from the API Gateway
• Data zone: Databases, message brokers — access only from the Application zone through defined ports
• Core banking zone: Legacy systems, ISO 8583 processing — strictest isolation
• Management zone: CI/CD, monitoring, SIEM — separated from production traffic
• PSD2 / Open Banking zone: TPP (Third Party Provider) endpoints with their own rate limiting and consent management

Rules between zones are defined as Kubernetes NetworkPolicies and Istio AuthorizationPolicies. The default is deny all — if a rule doesn’t explicitly allow communication, it doesn’t pass. Every rule has an owner, an expiration, and must pass security review.

Compliance: PSD2 and DORA¶

Security architecture in banking cannot exist in a vacuum — it must meet regulatory requirements. Two key regulations shaped our implementation:

PSD2 and Strong Customer Authentication¶

PSD2 requires Strong Customer Authentication (SCA) for electronic payments. This means at least two of three factors: something the user knows (password), has (phone), and is (biometrics). In a Zero Trust architecture, SCA is a natural extension — multi-factor authentication is not an exception, it’s the standard for every access to sensitive data.

For the Open Banking API (third-party access to account data), we implemented OAuth 2.0 with PKCE and dynamic client registration. Each TPP has its own identity in the IdP, its own rate limits, and its access is limited to the scope defined by user consent. Everything logged, everything auditable.

DORA — Digital Operational Resilience Act¶

DORA brought from January 2025 a mandatory ICT risk management framework, digital resilience testing, and incident reporting. Zero Trust architecture naturally addresses DORA:

• ICT risk management: Continuous monitoring, risk scoring, automated vulnerability scanning
• Incident reporting: SIEM with automated playbooks for classification and reporting within 4 hours
• Digital resilience testing: Regular penetration tests, red team exercises, chaos engineering
• Third-party risk: Every TPP and vendor has a defined risk profile and their accesses are monitored in real time

SIEM Integration and Continuous Monitoring¶

Zero Trust without monitoring is just marketing. The entire architecture generates enormous amounts of telemetry — and it must be centrally processed, correlated, and evaluated.

We implemented a SIEM (Security Information and Event Management) stack built on Elastic Security with custom detection rules. Key data sources:

• Envoy access logs: Every request between services — who, where, when, with what result
• IdP audit logs: Logins, MFA events, failed attempts, session revalidation
• OPA decision logs: Every authorization decision with full context
• Kubernetes audit logs: API server operations, RBAC changes, pod lifecycle
• Application logs: Business-level events, transaction logs

The key element is UEBA (User and Entity Behavior Analytics). ML models create a behavior baseline for every user and service. Anomalies — unusual access time, atypical data volume, access to unusual resources — automatically raise the risk score and can trigger step-up authentication or blocking.

We reduced the average MTTD (Mean Time To Detect) from hours to minutes through automation. MTTR (Mean Time To Respond) went from hours to tens of minutes thanks to SOAR playbooks that automate the first 80% of the incident response process.

How We Build It at CORE SYSTEMS¶

A Zero Trust implementation in banking is not a three-month project. It’s a transformation program requiring a systematic approach. Our process has four phases.

1. Assessment & Discovery (4–6 weeks): Mapping existing infrastructure, data flows, identities, and access patterns. Identifying crown jewels — systems and data requiring the highest protection. Gap analysis against DORA and PSD2.
2. Architecture & Design (4–8 weeks): Designing the target Zero Trust architecture, defining the segmentation model, selecting the technology stack. Proof of concept on a selected segment.
3. Iterative Implementation (3–6 months): Gradual deployment by segments, starting from the most critical systems. Each iteration includes deployment, testing, security review, and documentation.
4. Continuous Operations (ongoing): Monitoring, incident response, regular penetration tests, policy review, and architecture evolution based on new threats and regulatory changes.

An important aspect: we don’t overdo it. Zero Trust is not implemented overnight with a big-bang approach. Each phase delivers measurable security posture improvement and works independently. The client sees value from the first sprint — not after a year of work.

Our team combines specialists in network security, identity management, Kubernetes and service mesh, and compliance. We’re not just consultants delivering a PowerPoint — we build infrastructure, write policies, and operate monitoring. And then we hand it over to the client’s internal team with everything they need: documentation, runbooks, and hands-on training.

Conclusion: Zero Trust Is a Journey, Not a Destination¶

Zero Trust is not a state you achieve once and you’re done. It’s a continuous process — constant threat evaluation, policy tightening, resilience testing, and adaptation to new regulations.

Banks that approach it as a technology project with a clear end will be disappointed. Those that adopt Zero Trust as an operational philosophy — where every team understands the principles, every deploy passes security review, and every incident is an opportunity for improvement — will have infrastructure that can withstand both regulators and real attackers.