The Trust Your Zero-Trust Architecture Still Grants

What an examiner sees, and what nobody is looking at.

Since August 31, 2025, there has been no FFIEC-issued cybersecurity self-assessment tool. The FFIEC sunset the Cybersecurity Assessment Tool on that date, having announced the decision the previous September, and declined to update it. Institutions were told to refer instead to the NIST Cybersecurity Framework 2.0 and CISA's Cybersecurity Performance Goals. What a large bank measures about its own cloud security posture is now, to a meaningful degree, a matter of institutional choice.

Consider what that choice produces in practice. A federal examiner reviewing a large institution's cloud architecture under the FFIEC IT Examination Handbook's Architecture, Infrastructure, and Operations booklet will look for evidence of zero-trust controls. The institution will produce IAM policies, identity federation diagrams, network segmentation records, and perimeter controls. All of it will be real, and most of it will be good.

What the examiner is unlikely to see is a map of which workloads implicitly trust each other inside the VPC once IAM has said yes.

That surface is what lateral movement exploits after an initial credential compromise. In financial cloud environments, where the same infrastructure that processes payments also feeds Bank Secrecy Act reporting and sanctions-screening systems, a successful pivot inside a trusted VPC threatens the integrity of the financial-crime controls that U.S. supervisors rely on, not only the confidentiality of customer data.

What the standards require, and how far apart they are from each other

NIST SP 800-207, published in August 2020, defines zero trust as a set of principles rather than a product category. Its seven tenets are architectural: all communication is secured regardless of network location; access to individual enterprise resources is granted on a per-session basis; access is determined by dynamic policy including the observable state of client identity, application or service, and the requesting asset; and all resource authentication and authorization are dynamic and strictly enforced before access is allowed. The document separates the Policy Decision Point, comprising a Policy Engine that makes the access decision and a Policy Administrator that establishes or shuts down the communication path, from the Policy Enforcement Point, which enables, monitors, and eventually terminates the connection. The whole design is built around moving those components closer to the resource, so that network position confers nothing.

NIST closed the cloud-native gap three years later. SP 800-207A, published on September 13, 2023, sets out identity-based segmentation for cloud-native applications in five numbered requirements covering encrypted connections, service authentication through short-lived credentials, service-to-service authorization, phishing-resistant user identity management, and per-request user authorization. It names ingress proxies, sidecars, and egress proxies as the policy enforcement points, and requires that they be "always invoked (non-bypassable), verifiable, and independent of the application code." It specifies mTLS at the connection level with certificate lifetimes as short as fifteen to thirty minutes. It names SPIFFE explicitly, defining a SPIFFE ID as a string that uniquely identifies a workload, carried in a cryptographically verifiable identity document.

Most production AWS deployments in financial services implement the identity half of this model well. Role-based access control is mature. Service control policies at the AWS Organizations level enforce guardrails across accounts. Permission boundaries constrain what an assumed role can do. These controls address the Identity pillar of CISA's Zero Trust Maturity Model v2.0, which grades organizations across five pillars and four stages, from Traditional through Initial and Advanced to Optimal.

Strength in one pillar does not transfer to the others. Encryption of all internal traffic, east-west included, is an Optimal-stage requirement under the ZTMM Networks pillar's Traffic Encryption function, not something available at Advanced. Many financial cloud environments sit at Initial on Networks while sitting at Advanced or better on Identity, and read their overall posture from the pillar they are strongest in.

The specification gap is worth stating precisely, because it is not where most commentary places it. An IAM role assumption proves that the AWS control plane accepted a signed request from a principal holding the right permissions. It does not prove that the process making that call is the workload the role was assigned to, that the workload has not been compromised since the role was last assumed, or that the data-plane path carrying subsequent traffic is the path evaluated when the IAM decision was made. SP 800-207A's second requirement, service authentication through short-lived workload-scoped credentials, is the requirement that closes this. It is also the one AWS-native architectures most often leave open.

Four places where implicit trust enters the VPC

Four structural patterns recur across AWS reference architectures and public vendor research. Each looks like a zero-trust control. Each authenticates a principal rather than a workload.

1. VPC endpoint policies that authorize by principal, not by workload

A VPC endpoint policy for an S3 bucket or a DynamoDB table can restrict access to a specific IAM role.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::123456789012:role/PaymentProcessorRole"},
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::transaction-records/*"
  }]
}

This policy permits any process that can present credentials for PaymentProcessorRole. In an ECS cluster where several services share a task role, or in a Kubernetes cluster where IRSA binds a role to a service account that multiple pods can request, it grants access to a class of workloads. The endpoint policy looks like a zero-trust control. It is a coarse-grained authorization control that leaves workload identity unverified, and CloudTrail will not separate the callers beyond a session name.

AWS has shipped a partial answer. In March 2023 it introduced the global condition keys aws:EC2InstanceSourceVPC and aws:EC2InstanceSourcePrivateIPv4, which let a policy require that EC2 instance role credentials be used only from the VPC and private address they were issued to.

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:ec2InstanceSourceVPC": "${aws:SourceVpc}"
    }
  }
}

The boundary of that control is the instructive part. aws:SourceVpc is populated only when a request traverses a VPC endpoint, so any service without VPC endpoint support falls outside it, and AWS documents that actions such as mounting an EFS file system will be denied outright. The keys bind a credential to a network location, which is a real improvement over binding it to nothing. They do not bind it to a workload, and they say nothing about which process on that instance is making the call.

Deployment is thin. Datadog's 2025 State of Cloud Security study found that two in five organizations use data perimeters in AWS at all; of those, 32 percent implement them through S3 bucket policies and 13 percent through VPC endpoint policies, while fewer than 1 percent apply them at the organization level through service control policies or resource control policies. The control most often cited as evidence of cloud zero trust is, in the aggregate, both coarse and rarely placed where it would matter.

2. mTLS terminated at the load balancer rather than at the workload

Service meshes and application load balancers can enforce mutual TLS between services. AWS added mutual TLS to the Application Load Balancer in November 2023, with two modes: passthrough, which forwards the client certificate chain to the target in an HTTP header, and verify, in which the ALB validates the certificate against a trust store and terminates the connection.

In verify mode the workload receives an assertion it did not check and cannot independently confirm. Traffic between the termination point and the workload process is unencrypted and unauthenticated inside the pod network or the instance. A process that can reach that internal path, through a compromised sidecar, a misconfigured network policy, or a container escape, sits on the trusted side of the mTLS boundary without ever having authenticated. This is precisely the placement problem SP 800-207A addresses by requiring that policy enforcement points be non-bypassable and independent of application code.

3. IAM role-assumption chains that extend trust across account boundaries

Cross-account role assumption is standard practice in multi-account AWS architectures. A role in account A trusts a role in account B, which trusts a role in account C. Each link is individually auditable in CloudTrail. The chain as a whole appears in no single account's IAM policies.

AWS IAM Access Analyzer will not close this. Its external access analyzer applies automated reasoning to resource-based policies to identify resources reachable from outside a declared zone of trust, Region by Region, and it must be enabled in every Region in use. It evaluates edges, not paths. A three-account chain in which each hop sits inside somebody's zone of trust produces no finding at all, which is the exact shape of the problem. Transitive analysis requires separate tooling, graph-based IAM analyzers such as PMapper, and it requires the institution to treat the role-assumption graph as an artifact worth maintaining. The FFIEC AIO booklet's guidance on interconnected and third-party systems applies here: the institution is responsible for understanding the full trust graph, not just the local node.

4. VPC Lattice auth policies, which repeat the pattern in AWS's newest east-west control

The first three patterns predate 2023, and it would be reasonable to read them as legacy debt. The newest AWS service-to-service control shows otherwise.

VPC Lattice auth policies are IAM resource-based policies attached to a service or service network. When the auth type is AWS_IAM, requests must carry a valid SigV4 signature, and both the auth policy and the caller's identity-based policy must explicitly allow the action. The authenticated caller is an IAM principal: a user, a role, a federated user, a service, or an account. Lattice also supports anonymous principals, so a caller inside a VPC attached to the service network that does not sign with SigV4 can still be permitted if the policy allows it.

AWS shipped a Layer 7 service-to-service authorization control, positioned for zero-trust architectures, that authenticates an IAM principal rather than a workload and that permits an unauthenticated path by configuration. The gap is structural, not historical.

One mechanism, fully documented

The abstraction is easier to dismiss than the mechanism, so here is the mechanism.

In a default Amazon EKS configuration, a pod can reach the worker node's Instance Metadata Service and retrieve the node role's credentials with a single HTTP request to 169.254.169.254. No exploit is required beyond whatever gave the attacker execution inside the pod, an SSRF or an RCE in the application. The pod was authenticated as nothing and authorized by nothing. It inherited a role because it was running in the right place.

Datadog's published guidance is that enforcing IMDSv2 alone is not sufficient. The recommended configuration is IMDSv2 required, with http_put_response_hop_limit set to 1, plus a Kubernetes NetworkPolicy blocking pod access to the metadata endpoint. Both controls are network controls. Neither of them authenticates a workload; they restrict where an ambient credential can be picked up. The same study cited above found that 49 percent of EC2 instances enforce IMDSv2, up from 32 percent the year before, and that only 14 percent of instances two or more years old do.

What the guidance already says, and what it does not yet ask

The FFIEC has not overlooked system-to-system authentication. Its August 11, 2021 statement on Authentication and Access to Financial Institution Services and Systems, transmitted as OCC Bulletin 2021-36 and SR 21-14, is explicit that authentication scope covers "users accessing financial institution information systems, including employees, board members, third parties, service accounts, applications, and devices," and that "authentication considerations have extended beyond customers and include employees, third parties, and system-to-system communications." The supervisory expectation has existed for five years.

What does not exist is the translation into cloud data-plane terms. The 2021 statement was written in the vocabulary of user sessions, service accounts, and API credentials. It does not say what system-to-system authentication means when the two systems are a sidecar proxy and an application process sharing a network namespace, when the credential is an ambient instance profile that no party issued to a specific workload, or when the trust relationship is a three-account role chain that no single account's policy makes visible.

The AIO booklet, which is where an examiner would look for architectural criteria, was issued on June 30, 2021 and places zero trust at section VII.B, under "Evolving Technologies," alongside cloud computing, microservices, and machine learning. That placement was accurate in 2021. In 2026 it means that the one supervisory document addressing cloud architecture treats zero trust as something an examiner may encounter, rather than as an architecture with examination procedures attached.

Between a principle stated in 2021 and a procedure that would test it in a 2026 cloud environment, there is nothing. Examination frameworks necessarily lag architectural practice, and the CAT sunset was a defensible response to the proliferation of better external frameworks. The lag creates a specific and consequential risk: a financial institution can demonstrate mature IAM, documented segmentation, and a zero-trust policy, and satisfy every question actually asked, while leaving the data-plane trust gap entirely unaddressed.

What verified workload identity at the data plane requires

Closing the gap means treating workload identity as a cryptographic assertion rather than an inference from IAM role membership. Three changes follow.

Every service-to-service call inside the VPC should carry a short-lived, workload-specific credential that the receiving service verifies before processing the request. SPIFFE and SPIRE, the open standards that underpin most production service mesh implementations and that NIST names in SP 800-207A, issue SVIDs bound to a specific workload identity rather than to a role that many workloads share. AWS has moved partway toward this. EKS Pod Identity replaces IRSA's implicit OIDC trust-policy condition with an explicit, enumerable association between a service account and a role, retrievable through ListPodIdentityAssociations. That is a genuine auditability improvement. It is not workload authentication: the credential it delivers is a standard AWS session token retrieved from a link-local endpoint by way of the eks-auth:AssumeRoleForPodIdentity action, not a verifiable identity document bound to the workload. A receiving service still cannot verify who called it. It knows only that AWS accepted a signature.

mTLS should be enforced at the workload process boundary rather than at a network appliance boundary. This is operationally harder, because it requires the application or its sidecar to participate in certificate management, and it is the only configuration consistent with SP 800-207A's requirement that policy enforcement points be non-bypassable and independent of application code.

Role-assumption chains should be treated as a graph and analyzed as one. Since Access Analyzer evaluates edges within a zone of trust rather than transitive paths across zones, this requires deliberate tooling and a decision that the graph is a maintained artifact, reviewed as part of change management for every new cross-account integration.

Why this reaches beyond the institution

U.S. financial-crime controls depend on the integrity of the data that feeds them. Bank Secrecy Act reporting, OFAC sanctions screening, and the transaction monitoring systems that generate Suspicious Activity Reports all run on data held in cloud environments. An attacker who achieves lateral movement inside a financial institution's VPC and reaches the data stores behind those pipelines can corrupt or exfiltrate the information federal supervisors use to enforce compliance with federal law.

Supervisors have said the integrity of core banking and compliance systems is a priority. The interagency paper on sound practices to strengthen operational resilience, SR 20-24, revised June 2, 2026, applies to institutions with average total consolidated assets of $250 billion or more, or $100 billion or more with at least $75 billion in specified cross-jurisdictional activity, which is to say precisely the institutions running the largest financial cloud estates. The FFIEC's Joint Statement on Security in a Cloud Computing Environment set out cloud risk management principles for the sector in April 2020. The OCC's Cybersecurity and Financial System Resilience Report of June 2026, filed under the Consolidated Appropriations Act, 2021, restates operational resilience and supply chain risk as supervisory priorities.

The data-plane trust gap is a direct path to violating the integrity those documents are written to protect. Treating it as a matter of security hygiene understates what is at stake.

What should engineers do differently?

Treat IAM authorization and workload authentication as separate problems requiring separate controls. An IAM policy that permits a role is not a substitute for a cryptographic assertion that the calling workload is who it claims to be.

Concretely: verify SPIFFE SVIDs at the receiving workload rather than trusting the mesh to have done it; terminate mTLS at the process boundary rather than at the load balancer; apply the EC2 instance source-VPC condition keys where the service supports VPC endpoints, and document explicitly which services do not; enforce IMDSv2 with a hop limit of 1 and block metadata access at the network layer as well; and build role-assumption chain analysis into security review for every new cross-account integration.

What supervisors should ask

A revised examination framework for cloud environments does not need a new theory of zero trust. It needs questions specific enough that an institution's answer either produces evidence or exposes the gap. Six would cover most of it.

1. For each service-to-service call path that reaches a system of record feeding BSA reporting, what credential does the receiving service verify, and what does it verify it against?
2. Where is mTLS terminated relative to the workload process, and what traverses the segment between the termination point and that process?
3. Produce the role-assumption graph, including cross-account edges. Identify every path of length two or greater that terminates at an in-scope data store.
4. Which VPC endpoint policies constrain access by workload attribute rather than by IAM principal alone, and which condition keys implement that constraint? For services that do not support VPC endpoints, what compensates?
5. For workloads on EC2 and EKS, is IMDSv2 enforced with a hop limit of 1, and is metadata access additionally blocked at the network layer?
6. What is the maximum credential lifetime for service-to-service authentication, and what component issues and rotates those credentials?

Asking whether an institution has a zero-trust policy is not the same as asking whether its workloads verify each other's identity before exchanging data.

If your institution's zero-trust documentation were handed to an engineer who had just achieved lateral movement inside your VPC, would they find anything in it that would have stopped them?

The annotated reference architecture for this article, with each boundary mapped to the NIST SP 800-207A requirement it leaves unmet and to the examination question that would surface it, is published in the aws-trust-boundaries repository under CC BY 4.0.

Written in a personal capacity. All analysis draws on public standards, public vendor documentation, and published research.