Zero Trust ATM Connectivity: Securing Transactions with NetFoundry

Zero Trust ATM Connectivity: Securing Transactions with NetFoundry

Learn how to eliminate inbound firewall ports, segment ATM traffic, and simplify PCI DSS 4.0 compliance using NetFoundry’s zero-trust networking architecture.

This demonstration by NetFoundry Senior Sales Engineer Flavio Corrasco details a zero-trust approach to securing ATM connectivity. Traditional ATM deployments often rely on flat branch networks, unencrypted local connections, and open inbound firewall ports, exposing them to man-in-the-middle attacks and network scanners. NetFoundry addresses these vulnerabilities by converting ATMs into “dark endpoints” using outbound-only connections and mutual TLS (mTLS) authentication. This architecture isolates ATM traffic, eliminates discoverable attack surfaces, and provides explicit per-ATM routing policies, significantly streamlining PCI DSS 4.0 compliance without requiring recertification of the ATM’s operating system image.

Key Takeaways

  • Vulnerabilities in Traditional Setups: Legacy ATM networks often share flat VLANs with VoIP or POS systems, leave local router connections unencrypted, and require open inbound firewall ports (like port 8583), creating opportunities for transaction manipulation and network intrusion.
  • Creating Dark Endpoints: By deploying NetFoundry Ziti, ATMs establish outbound-only 443 connections to a zero-trust fabric. This removes all listening ports and discoverable IP addresses, making the ATM completely invisible to external scanners and rogue network devices.
  • Simplified Compliance and Control: The solution provides explicit, per-ATM access policies and end-to-end mTLS identity verification. Because it can be deployed as an appliance alongside the ATM, it achieves strict segmentation for PCI DSS 4.0 without altering the machine’s OEM-certified software image.

Frequently Asked Questions

What are the primary security risks of traditional ATM networks? ATMs frequently sit on flat branch networks shared with less secure devices (like cameras or VoIP phones). Additionally, local connections between the ATM and the router are often unencrypted, and data centers typically rely on open inbound firewall ports to receive transactions, creating a broad attack surface for host spoofing or man-in-the-middle attacks.

How does NetFoundry protect against man-in-the-middle attacks? NetFoundry secures the connection end-to-end using mutual TLS (mTLS) certificate-based identity. This means every device must cryptographically prove its identity before communicating, preventing rogue devices from intercepting or rewriting transactions on the local network.

What is a “dark endpoint” in this context? A dark endpoint is a device that has no listening network ports, no discoverable IP address, and zero inbound firewall rules. The ATM relies entirely on outbound-only connections to the NetFoundry fabric, making it invisible to attackers scanning the network.

How does this architecture assist with PCI DSS 4.0 compliance? PCI DSS 4.0 requires strict network segmentation and documented proof of isolation every six months. NetFoundry isolates each ATM into its own segment with explicit per-ATM routing policies, drastically simplifying the documentation and auditing process for compliance.

Does installing this solution void the ATM’s certified software image? No. Because the solution can be deployed as a sidecar appliance next to the ATM, it requires no changes to the certified operating system image and avoids triggering complex OEM recertification processes.

Full Transcription

Hello everyone, Flavio Corrasco, senior sales engineer with NetFoundry. For today’s demo, we have a zero trust approach to ATM connectivity.

This architecture carries several compounding risks. ATMs sit on a flat branch network sharing a VLAN with cameras, point of sale terminals, and voice over IP systems rather than being segmented off. The local connection between the ATM and the router is often unencrypted, leaving it exposed to host spoofing or man-in-the-middle attacks capable of rewriting a declined transaction as approved. Even on the WAN leg where TLS is server-cert only with no mutual authentication, a setup where misconfigured certificate chains are a common source of failure. Compounding this, the DMZ firewall has an inbound listener open on port 8583 for the acquirer switch, making it reachable and scannable from the outside.

Taken together, these gaps make it difficult to segment and document the branch network in a way that satisfies PCI DSS 4.0 requirements that must be reproven every six months.

So for this demonstration, you have a security network engineer which is tasked with rolling out a new standalone ATM running on Windows LTSC inside a private AWS subnet that needs to reach the backend services hosted in a private DC, without ever exposing the ATM to public internet.

Instead of opening inbound ports or building a traditional site-to-site VPN, the engineer installs NetFoundry Ziti tunnel directly on the ATM host, which turns the ATM into a dark endpoint—no listening port, no discoverable IPs, no attack surface.

The tunnel makes an outbound-only 443 connection into the NetFoundry Fabric overlay, a zero trust network fabric spanning on both networks. And then you have in the private DC, you have an edge router that joins the same overlay providing the on-ramp into the private subnet to access the backend services.

So what does this look like here in the demo, you have General Bank has three locations, you have your corporate office, you have your bank back-end office (this is what’s located in your private DC) and then you have your General Bank US ATMs. You can kind of see here there’s one in Frisco, Dallas, and Atlanta. So for today I’ll be using the Dallas branch to deploy. And you can kind of see here I have created an ATM backend access policy where I list all the ATMs that will be accessing the destination of your backend services here.

So if I go to the demo, I go to my Dallas ATM branch, I enter my debit card number and then my PIN, and then you can start your banking transactions. You could check your balance, go back to menu, you could do a withdrawal, and then you can go back and say you want to deposit your funds, confirm the deposit. So you have a total, your balance is 2500, right? So you could also—for some reason there’s a discrepancy, the customer calls, you know the deposit didn’t go through, the administrators have access to the backend as well. So you can kind of refresh this page, you’ll see it was 2500 balance here, I could edit, change that to 3000. Go back to the ATM, do a query of the balance, as you can kind of see here the transactions from the AWS to the backend private DC and back and forth is pretty much near real-time, there’s no lag or delay.

And if for some reason you feel like this host has been compromised, you want to quarantine or remove the Dallas branch from accessing the backend, you can very similarly go back to the access policy, remove the Dallas branch, and then within seconds you will notice that this ATM has no longer access to the ATM backend office. So I could say go back to the main menu, if I check my balance, you have a connection error which, you know, as you can see I could easily add and remove from the access policy and you know to grant and allow access here.

And a couple of things to note. You can kind of see here the URL, the atm.dallas.web gave me access to this ATM, but if you go off and insert this into just your public browser that does not have a policy or Ziti client installed on your machine, you will not have access to this URL. So with that said, let me go finish here.

As you can see, this was the current state stated on the first slide, and then when you incorporate this with NetFoundry, you can kind of see that each ATM becomes its own isolated segment, with no path to cameras, point of sale terminals, or the branch LAN. There are zero inbound firewall rules on either end; both ends only dial out, which leaves nothing to scan. The connection is secure end-to-end with mTLS certificate-based identity, which means a rogue device has no credentials to present and can’t spoof its way onto the network.

And this closes the actual ATM-to-router gap the OEM worried about, not just router-to-host, and gives you explicit auditable per-ATM policy, a natural fit for PCI DSS 4.0 compliance. Because it’s deployed as an appliance beside the ATM, there’s no change to the certified image and no OEM recertification is required.

So as you can see here, there’s nothing to scan, nothing to exploit. And that ends the demo for today. Hopefully you enjoyed, stay tuned for more. Thank you.