Traditional security often treated a user or device inside a bank's network as more trustworthy than one outside it. Zero trust removes that automatic assumption and makes access depend on verified identity, device condition, the requested resource and current policy each time a protected interaction is established.
Network location no longer grants implicit trust
A branch workstation, corporate laptop or application in a private data center can still be compromised. Zero trust therefore focuses protection on users, devices, workloads and resources rather than treating a network segment as a safe interior surrounded by an unsafe internet.
This does not mean the bank trusts nothing or repeatedly challenges every customer with the same visible step. It means trust is not permanent or inherited from location: authentication, authorization and device or workload checks provide evidence for a defined decision under policy.
Identity, device and resource inventories form the foundation
The bank needs to know which people, service accounts, machines, applications, data and interfaces exist, who owns them and how sensitive they are. Unknown assets and shared credentials undermine precise decisions because policy cannot distinguish an approved workload from an ungoverned path.
Strong identity lifecycle controls remove access when roles change, while device and workload identity let policy evaluate non-human actors as well as employees and customers. Classification of resources helps the bank apply stronger evidence and narrower privileges where the potential customer, financial or operational impact is greater.
Policy separates the access decision from enforcement
A policy decision point evaluates available signals such as identity, authentication strength, device posture, requested action, time, location, known threats and resource sensitivity. A policy enforcement point then allows, limits, challenges or blocks the connection in the application, gateway, network or other control layer.
The architecture works best when policy is explicit, testable and connected to reliable data. Conflicting rules, stale inventories or unavailable signal providers can create unsafe access or widespread lockouts, so decision and enforcement components need resilient design, change control and safe failure behavior.
Least privilege and continuous signals limit exposure
A successful login should not provide broad, long-lived access to unrelated systems. Permissions are limited to the task, resource and period needed, and sensitive actions may require stronger evidence, separate approval or a newly evaluated session.
Risk can change after access begins. Device health, credential compromise, unusual behavior or a higher-risk request may cause the bank to shorten a session, step up authentication or terminate access. Continuous verification means re-evaluating relevant evidence, not endlessly collecting data without a defined purpose or control decision.
Migration is an operating program, not a single product
Banks can begin with high-value use cases such as privileged administration, remote access, cloud workloads or sensitive data services, then expand as inventories, identity and telemetry improve. Older systems may require gateways, compensating controls or staged replacement when they cannot enforce modern, resource-level policy directly.
Zero trust does not eliminate software flaws, social engineering, insider misuse, provider outages or the need for network defenses and recovery plans. Governance should test access outcomes, privacy impacts, emergency procedures, third-party connections and concentration in identity or policy services so a stronger control does not become a new single point of failure.
Read the primary material
Banking Explained prioritizes regulators, official publications and first-party announcements.