Security Architecture and Zero Trust

Resource protection, least privilege, identity and policy enforcement

Avoid implicit trust from network location

Zero trust treats access to resources as a decision requiring appropriate identity, authority and context, rather than assuming that being inside a network is sufficient. NIST SP 800-207 describes the approach and logical policy components.

It is not one product, a mandatory service mesh or a guarantee that every risk disappears. Network controls remain useful. A bank can adopt the principles incrementally across different architectures, including legacy systems and controlled exceptions.

Resource access combines actor and device context, policy assessment, enforcement and continuing evidence.

Identity and resource authority

Distinguish human, workload, client and device identities. Authenticate appropriately and grant only required actions on the relevant resources. A cryptographically valid assertion can establish its issuer and integrity without proving every underlying identity or business fact.

Protect sessions and use suitable lifetimes, revocation and action checks. Passkey login does not automatically protect every later token from replay. Workload identity and short-lived credentials can reduce secret exposure, but issuance, permissions, rotation and recovery still need controls.

Privileged access should be justified, scoped and evidenced. Just-in-time elevation can reduce standing exposure; some operations may still require controlled standing permissions or emergency access. The actual design should preserve accountability rather than declare all exceptions impossible.

Devices, networks and applications

Device posture, attestation and behavioural signals can inform access. A compromised device does not make the user's legal identity cease to exist, and an attestation result does not prove the absence of every malware threat. Provide proportionate safe paths for legitimate customers.

Segmentation and egress controls limit potential movement and exposure. They do not require every workload to occupy a unique subnet or every request to cross one physical gateway. Encryption and mutual authentication need suitable protocols and key management; zero trust does not impose TLS 1.3 as a worldwide statutory requirement.

Enforce API resource and action permissions server-side. Schema checks, rate limits and transport encryption cannot replace authorisation. Customer mandates and product restrictions must influence relevant financial actions even if an internal service authenticates successfully.

Data and software integrity

Classify important data, minimise access and protect storage, transmission and backups under the actual requirements. Pseudonymisation is not necessarily anonymisation. Encryption does not permit unrestricted sharing or remove the need for retention and purpose controls.

Secure build and deployment practices can include dependency management, provenance, signing and vulnerability assessment. Signing does not guarantee that approved code is safe; a software bill of materials does not itself remediate vulnerabilities. Evaluate actual exposure and effective controls.

Policy availability and observation

Policy decision and enforcement components can be distributed. One global policy engine can itself create a critical dependency. Define cached decisions, policy versions, fallback and expiry according to the resource and risk; neither universal fail-open nor universal shutdown is suitable for every operation.

Monitor denied access, excessive permissions, drift and unusual effects. Test meaningful attacker paths and legitimate work. Continuous verification does not mean asking every user to enter a password on every API call.

Fictional example: valid service identity, wrong account

A trusted payment service requests a statement for an account outside its scope. The data service checks resource authority and rejects the request despite valid service authentication and an internal network location. It records enough context for investigation without logging unnecessary financial data.

Takeaway

Zero trust makes resource authority and context explicit. Its value comes from enforced least privilege and reliable decisions, supported by usable recovery and evidence.