Vicedomini Softworks

Software Security

Zero Trust for Applications: Architecture and Practice

21 October 2026

Engineer mapping application service boundaries

Zero Trust for applications is the practice of removing implicit trust from every interaction an application takes part in: between a user and the application, between one service and another, and between the application and its data. Instead of assuming that a request is legitimate because it originates inside a corporate network, each request is authenticated, authorised against an explicit policy and evaluated in context. For application teams this means that identity, not network location, becomes the primary security boundary, and that security controls are engineered into the software and its delivery pipeline rather than layered on afterwards.

Vicedomini Softworks
Build Security Into Your Applications
Vicedomini Softworks engineers custom software with security practices, production monitoring, and ongoing support built into the development lifecycle.
Ask for a consultation

TL;DR

  • Zero Trust is an architectural approach, not a product: every request is verified, access is limited to the minimum necessary, and a breach is assumed as the design baseline.
  • For applications, the shift is from network-based policies (IP addresses, segments) to identity-based policies for users, services and workloads, as NIST SP 800-207A recommends for cloud-native systems.
  • Non-human identities (service accounts, API keys, tokens) are frequently the weakest point, and short-lived, automatically rotated credentials are the corrective.
  • The effective path begins with an audit of existing applications, prioritises the mission-critical ones and embeds controls in CI/CD.

Table of Contents

What Zero Trust means once the perimeter is gone

The traditional model treated the corporate network as a trusted zone and the internet as a hostile one. Remote work, cloud hosting, third-party APIs and SaaS integrations have dissolved that boundary. NIST SP 800-207 describes zero trust as an evolving set of paradigms that move defences from static, network-based perimeters to users, assets and resources. The UK National Cyber Security Centre frames it similarly: inherent trust in the network is removed, the network is assumed hostile, and each request is verified against an access policy.

The three principles most often cited, and described by Google Cloud in its overview, are to verify explicitly, to apply least privilege, and to operate on the assumption that a breach has already occurred. None of them is specific to applications, yet each acquires a particular meaning when the protected asset is a piece of software that exposes APIs, consumes secrets and calls other services.

A clarification on terminology is useful here. Zero Trust Network Access (ZTNA) and Zero Trust Application Access (ZTAA) are access-layer patterns in which requests are brokered through a secure proxy, so that only authorised users or services reach the specific resource they need, as Check Point explains. They are components of a Zero Trust strategy. They do not, on their own, make the application itself resistant to lateral movement, abuse of service credentials or insecure internal calls.

Why applications need their own Zero Trust model

Securing user access to an application is only the first layer. A modern application is a graph of components: a front end, an API gateway, several back-end services, queues, databases and third-party integrations. Each edge in that graph is a potential path for an attacker who has obtained a foothold anywhere. A model that authenticates the human at the entrance and then trusts everything behind it reproduces, inside the application, the very perimeter assumption that Zero Trust seeks to eliminate.

The CISA Zero Trust Maturity Model 2.0 treats applications and workloads as one of its five pillars, alongside identity, devices, networks and data. It describes four maturity stages (Traditional, Initial, Advanced and Optimal) and places at the optimal end continuous authorisation, real-time risk analysis and automated security processes integrated across application workflows. The practical implication is that application security is assessed as a distinct discipline, with its own trajectory, and not as a by-product of network controls.

Identity-based policy instead of network-based policy

For cloud-native systems, NIST SP 800-207A (September 2023) sets out an access-control model for multi-cloud environments in which implicit trust based on network location, affiliation or ownership is removed from users, services and devices alike. The consequence for engineering is a move away from rules expressed as IP ranges and subnets, which are brittle in environments where containers are created and destroyed continuously, towards rules expressed in terms of who or what is calling.

The following table summarises the difference in how the same concerns are handled under each approach.

Concern Perimeter and network-based approach Zero Trust, identity-based approach
Service-to-service trust Any workload inside the network or segment may call another Each call authenticated with workload identity, typically over mutual TLS
Policy expression IP addresses, ports, VLANs, security groups Service identity, role, attributes and context of the request
Credentials Long-lived API keys and static service accounts Short-lived, automatically issued and rotated credentials
Blast radius of a compromised service Frequently the whole segment Limited to what that identity is explicitly permitted to do
Portability Tied to the network topology of one environment Consistent across clouds and data centres
Where controls live Perimeter appliances and network configuration Application code, service mesh, gateways and the delivery pipeline

The NIST publication notes that modern distributed architectures combine API gateways, sidecar proxies and identity infrastructure to enforce granular policy regardless of where a workload runs. Identity frameworks such as SPIFFE, which issues cryptographically verifiable identities to workloads, are the usual mechanism for the last of these.

Non-human identities: the overlooked attack surface

Most Zero Trust discussions begin with employees and their devices. In application architectures the larger population is non-human: service accounts, API keys, tokens, certificates, bots and automated workloads. The OWASP Non-Human Identities Top 10 defines these identities as the means by which software entities identify, authenticate and authorise themselves to access secured resources, and it dedicates an entire risk list to their misuse.

Among the risks that list names are improper offboarding and secret leakage. The first concerns service accounts and access keys that remain active after the service they belonged to has been retired. The second concerns API keys, tokens and certificates that end up hard-coded in source code, stored in plain-text configuration or shared through chat tools. In both cases the credential outlives its purpose and is rarely monitored, which is precisely what makes it attractive to an attacker seeking persistent, quiet access.

The corrective principle is consistent across the guidance: replace long-lived static secrets with short-lived credentials that are generated automatically and bound to a verifiable workload identity. Rotation then ceases to be an operational chore dependent on human discipline and becomes a property of the platform. If a credential is exfiltrated, its useful life is measured in minutes rather than months.

Service-to-service authentication in microservices

A recurrent anti-pattern in microservice systems is to authenticate a user once at the edge, typically with a JSON Web Token, and then to propagate that token through every downstream call as the sole proof of legitimacy. If the token leaks, or if any internal service is compromised, the attacker inherits a credential that every other service accepts, and lateral movement becomes straightforward. The NIST model for cloud-native access control addresses this by separating policy into two tiers.

The network tier provides general segmentation, limiting which workloads can reach which others at the transport level. The identity tier then requires services to authenticate each other, using mutual TLS and validated identity tokens, so that a service which happens to be reachable still cannot be abused without valid internal credentials. The two tiers are complementary: network segmentation reduces exposure, while identity-tier policy supplies the verification that segmentation alone cannot provide.

The OWASP Microservices Security Cheat Sheet collects the surrounding practice, including authentication and authorisation between services, and is a useful checklist for teams reviewing an existing architecture. In practice, a service mesh is the most common way to obtain mutual TLS and identity-aware routing without rewriting every service, though it introduces operational complexity that must be justified by the size and sensitivity of the estate.

Service-to-service authentication in microservices — overview diagram

Zero Trust in the cloud

Cloud environments make the case for Zero Trust more acute and, paradoxically, easier to implement. They make it more acute because the network is shared, programmable and exposed by default to configuration error. They make it easier because identity and policy are exposed as first-class platform features: managed identities, short-lived tokens issued by the provider, fine-grained role definitions and native logging. Microsoft’s guidance for Azure summarises the strategy as assuming breach and verifying each request as though it originated from an uncontrolled network, which is a concise statement of the posture an application should adopt regardless of the provider.

Multi-cloud and hybrid deployments add a further requirement: policy must remain consistent when a workload moves between environments. This is the reason NIST frames its application model around identity rather than around any single provider’s network constructs. Where an organisation runs Kubernetes-based platforms, for instance on Red Hat OpenShift, the platform’s service accounts, network policies and mesh capabilities provide the building blocks, but they must be configured deliberately. A default installation is not a Zero Trust architecture.

Building Zero Trust into the delivery pipeline

One of the recurring findings in the guidance is that Zero Trust fails when it is treated as a filter applied after the software is built. The CISA model’s optimal stage expects security processes to be automated and integrated into application workflows, which in engineering terms means DevSecOps. Several controls belong in the pipeline itself.

Secret scanning on every commit prevents the leakage patterns identified by OWASP before they reach a repository’s history. Dependency and container image analysis addresses the vulnerable third-party components that the same OWASP list highlights as a risk for external integrations. Infrastructure as code allows network and identity policy to be reviewed, versioned and tested like any other change. Finally, observability, meaning structured logs, traces and metrics tied to identities, supplies the continuous evaluation that a Zero Trust posture presupposes. Without it, policy can be written but its effectiveness cannot be demonstrated.

The NCSC’s design principles begin with knowing the architecture, including its users, devices, services and data, and with knowing every user, service and device identity. That inventory step is also where legacy components surface, since services that cannot support modern authentication are the usual obstacle to an otherwise orderly transition.

A phased path for an existing application estate

Organisations frequently approach Zero Trust as a purchase. The CISA material and the practitioner consensus behind it point the other way: it is an architectural evolution, and the common pitfall is trying to secure everything at once. A sequence that has proved workable is set out below.

Phase Objective Typical outputs
1. Inventory and audit Identify applications, data flows, identities and dependencies, and rank by criticality Application register, identity inventory, dependency map, risk ranking
2. Identity foundation Establish strong authentication for users and workload identities for services Central identity provider, MFA, secret management, short-lived credentials
3. Protect the critical applications Secure inter-service communication for the mission-critical systems first mTLS, identity-tier policies, API gateway enforcement, service mesh where justified
4. Automate and observe Move controls into CI/CD and instrument for continuous evaluation Pipeline scanning, policy as code, centralised logging and alerting
5. Expand Extend the pattern to the remaining estate and retire legacy exceptions Modernised or isolated legacy components, periodic maturity reassessment

The ordering matters. Starting with the most sensitive applications ensures that the data carrying the highest risk receives the strongest protection while the organisation builds the skills and tooling to extend the model. Reassessing against the CISA maturity stages at intervals gives a defensible measure of progress, and avoids the common failure of declaring the programme complete once a single tool has been deployed.

Common mistakes

The first is equating Zero Trust with a product category, such as ZTNA gateways, and consequently leaving internal service communication untouched. The second is the edge-token pattern described above, in which a single bearer token is trusted by every downstream service. The third is neglecting non-human identities, so that human accounts are protected by MFA while service accounts retain broad, permanent privileges. The fourth is introducing controls without observability, which produces friction without evidence. The fifth is ignoring legacy systems, which then become the path of least resistance around the new controls.

Our perspective

We build and maintain custom software for organisations across EMEA and North America, and the pattern we meet most often is not an absence of security tooling but an absence of a coherent application-level design. Network controls are present, an identity provider is in place, yet services still trust one another by default and credentials are long-lived because rotating them was never part of the original architecture.

Our perspective — overview diagram

Our view is that Zero Trust for applications is decided at the design stage, in decisions about service boundaries, how identities are issued, how secrets are handled and what a compromised component can reach. These are engineering decisions with business consequences, and they are cheaper to make before a system is built than to retrofit. That is one reason we work without an account-manager layer: the engineers who design the architecture are the same people who explain its trade-offs to the client, so a decision such as adopting a service mesh, or deliberately deferring it, is taken with a clear view of cost, operational burden and risk.

We also hold that written recommendations matter. A consulting engagement that ends in a conversation leaves nothing to audit, whereas a documented assessment of applications, identities and dependencies gives an organisation a baseline against which progress can be measured. Where legacy systems cannot meet the standard, we prefer to say so plainly and to propose either modernisation or containment, rather than to certify an architecture that the code does not support.

— Pepe F.

Where Vicedomini Softworks can help

For organisations that need to establish where their applications stand before committing to a programme, we offer an initial assessment from €3,500 as a one-off engagement, and ongoing technical leadership through three subscription levels: CTO Advisory from €1,800 per month, Fractional CTO from €4,000 per month and CTO Partner from €7,500 per month. Details are on the CTO subscription page. Architecture and stack selection, code audit and technical debt review, and custom software development are described under our services, and examples of delivered work can be found in the case studies.

FAQ

What is Zero Trust in simple terms?

Zero Trust is a security model that grants no request implicit trust, whether it comes from inside or outside the corporate network. Each request is verified, authorised with the minimum privilege required, and evaluated on the assumption that a compromise may already exist. Google Cloud’s overview describes it as a model in which no person or device is trusted by default.

What principle is the Zero Trust model based on?

It rests on three linked principles: verify explicitly, use least-privilege access, and assume breach. The practical effect is that location on the network confers no privilege, and that every access decision relies on identity and context.

What is ZTNA, and how does it relate to applications?

Zero Trust Network Access is an architecture that brokers connections to applications through a secure proxy, so that users reach only the specific resources they are authorised to use. Its application-focused variant, ZTAA, applies the same logic to individual applications. Both control access to the application but do not by themselves secure communication between its internal services.

Can Zero Trust be bought as a single solution?

No. Tools such as identity providers, gateways and service meshes support it, but the NIST and CISA material treats it as an architectural approach that matures in stages. Success depends on auditing existing applications, prioritising the critical ones and building controls into the development pipeline.

Where should an organisation start?

The starting point is an inventory of applications, data flows and identities, including non-human ones, followed by a ranking by criticality. The most sensitive applications are then secured first, beginning with strong identity and protected inter-service communication.

Sources

This article was produced with AI assistance and reviewed for accuracy. It is provided for general information only and is not professional advice.