Senior Solutions Architect, Nic Fragale, demonstrates NetFoundry’s Customer Connect, which is an innovative networking solution designed to eliminate the complexities, security vulnerabilities, and slow onboarding times associated with traditional VPNs and firewalls. By utilizing a lightweight connector or embedded SDK, the platform enforces a zero-trust model where every connection authenticates first via mutual TLS before anything is reachable.
This architecture leaves zero open inbound ports and scopes access strictly to identity and workload. Ultimately, Customer Connect empowers providers to onboard customers in minutes instead of weeks, which accelerates sales cycles, drives faster revenue recognition, and significantly lowers operational costs—all while meeting strict compliance frameworks like HIPAA, PCI, and NIST.
Key Takeaways
- Rapid, Frictionless Onboarding: Replaces weeks-long, complex VPN and firewall configurations with a lightweight connector that deploys in minutes, requiring zero customer-side firewall, DNS, or IP changes.
- Zero Trust Security: Eliminates external attack surfaces by authenticating all connections first via mutual TLS, ensuring zero open inbound ports and restricting network access strictly by user identity and workload.
- Scalability and Business Acceleration: Leverages repeatable templates to scale customer deployments effortlessly, resulting in shorter sales cycles, faster revenue recognition, and significantly reduced operational overhead.
Frequently Asked Questions
1. How does NetFoundry Customer Connect improve customer onboarding compared to traditional VPNs? Customer Connect dramatically accelerates onboarding by replacing complex, time-consuming VPN and firewall setups with a lightweight connector or embedded SDK. Unlike traditional methods that require extensive network configuration, Customer Connect deploys in minutes and requires zero firewall, DNS, or IP changes on the customer side. This eliminates weeks of ticketing and troubleshooting, allowing you to recognize revenue faster and reduce operational overhead.
2. How does Customer Connect implement Zero Trust security? Customer Connect enforces a true Zero Trust model by ensuring that every connection authenticates first via mutual TLS before any resource becomes reachable. This architecture leaves zero open inbound ports, effectively eliminating the external attack surface. Access is strictly scoped to the user’s identity and specific workload, rather than their network location, preventing lateral movement and unauthorized access within the network.
3. Can Customer Connect scale for multiple customers and enterprise deployments? Yes, Customer Connect is explicitly designed for scale. Once you have configured the access policies and connectors for your initial deployments, you can capture those configurations as repeatable templates. This means subsequent customer onboardings are simply copies of existing models rather than complete rebuilds. Everything is managed from a single control plane, allowing providers to effortlessly stamp out new deployments and scale their business without increasing network engineering complexity.
Full Demo Transcript
Hi there. My name is Nick Fragale. I am a senior solutions architect here at NetFoundry. It is my pleasure today to show you a brand new solution from NetFoundry called Customer Connect.
I’m going to go over what use case this solves, why it’s important to you, and exactly what type of benefits you should expect to see while giving you an awesome demo.
Let’s begin.
Every provider deployment starts the same. Another VPN, another exception, another firewall rule that breaks the moment the customer changes anything. That sprawl is your attack surface. Inbound ports, shared credentials, flat networks wide open to lateral movement. And it doesn’t scale. Every new customer is another ticket, another cert rotation, weeks of onboarding instead of minutes. Customer Connect ends this.
Customer Connect flips the model. Embed the SDK once, or drop in a lightweight connector. Deployment takes minutes with zero firewall, DNS, or IP changes on the customer side. Every connection authenticates first—mutual TLS before anything is reachable. There’s no open inbound ports to attack. Access is scoped to identity and workload, never network location. And it’s all managed from one plane across every customer at scale.
On the demo setup, I’ve got a scenario: DynaNick Corporation’s client device as a customer pulling access to a resource NetFoundry, the provider, owns. Plus a separate resource sitting inside DynaNick’s own subnet that it’s been granted access to through the same connection. That’s a good way to show the architecture of a provider workload and customer on-prem path both resolving through the same client with zero re-configuration on either side.
This is the NetFoundry provider’s dashboard for customers onboarded, each with their own locations, connectors, and usage telemetry. DynaNick is the one we’ll drill into.
Inside of DynaNick, my client device is registered as one of the two active connectors. Connectors are how anything gets on this network. They come in three forms: a device connector that exposes a local resource, a gateway connector that forwards to anything reachable behind it, or an SDK embedded directly into an application.
Mine’s a device, which you can see here: the client running on my MacBook. That’s what’s letting this machine participate in DynaNick’s network.
Let’s take a look at the access policies granting connectors their reach.
Let’s grant DynaNick’s employees the access they require.
The source will be DynaNick’s location: the employees.
And on the destination side is a resource that lives within DynaNick’s own network. I have it selected here.
I’ll do the same for the provider’s resource. Let’s grant DynaNick employees the access that the provider gives them.
Reachability isn’t about whose network you’re sitting on because it’s the same connector here and there’s two different ownership domains. It’s about what the policy explicitly grants. My device now has access to two different types of resources: one in DynaNick and two in the NetFoundry provider.
Let’s take a look at the DynaNick customer now. We see two different access policies granted. One allows me to get to the virtual desktop that my company, DynaNick, provides me. Let’s give that a shot.
Great. The RDP session loads up. My machine has explicit access to this resource, and nothing more.
Once you’ve onboarded a handful of customers, the pattern repeats. Templates capture everything that defines a customer, so the next onboarding is a copy, not a rebuild. Models do the same thing for connectors. Construct one once, then stamp out the next in minutes. That’s what makes this scale past customer number one.
We can see that by clicking on Templates. I can go to a customer and create a template from it. I can also go to a model and create a new model from an existing type, giving it application access, granting it access right in the model, ready to be copied.
This is what it all adds up to. Deployments go live in minutes, not months. Security objections shrink, so sales cycles shrink with them. Faster deployment means faster revenue recognition. Less networking overhead per customer means lower ops cost at scale. And zero trust access with no inbound attack surface means stronger security than what you had before—not a trade, an upgrade.
It’s built to meet FIPS, HIPAA, PCI, NIST, and a dozen other frameworks you already answer to.
This is the solution you were looking for.
I want to say thank you for watching and learning about Customer Connect today. NetFoundry’s solution for onboarding customers at scale securely is quite an amazing thing. We hope we can show it to you. Let us know how we can help you and reach out to us today. Thank you.
