PKI for Network Devices: How Avassa Handles Certificates at the Edge
Network equipment at the edge, routers, switches, gateways, access points, needs to prove its identity just as much as any server in a data center does. But managing PKI for these devices brings its own set of problems: they’re distributed across many sites, they don’t always have a reliable connection back to a central network, and they often run on hardware that wasn’t designed with modern certificate lifecycles in mind.
Here’s how Avassa approaches PKI for network devices, and what we think makes the difference between a system that looks good on paper and one that actually holds up when a site goes offline.
Bringing your own CA certificate into the picture
The Avassa Control Tower can import CA certificates directly or connect to an Enterprise CA system. Connection from Avassa to a CA system is typically configured using ACME or EST.
This means you don’t have to stand up a parallel trust infrastructure just to manage your edge devices. If your organization already has a CA it trusts, Control Tower plugs into it rather than asking you to replace it.
EST and SCEP – differences
| SCEP | EST | |
|---|---|---|
| Defined in | RFC 8894 (2020), originally a Cisco draft from the late 1990s | RFC 7030 (2013) |
| Transport | Plain HTTP; security is applied at the message level (PKCS#7/CMS signing and encryption) | HTTPS; TLS itself authenticates the server and encrypts the channel |
| Client authentication | A shared challenge password embedded in the CSR, a bearer secret | A TLS client certificate, or HTTP Basic auth over TLS as a fallback |
| Key/algorithm support | Originally RSA only; RFC 8894 added ECC support | No protocol-level restriction; works with RSA, ECC, and newer algorithms as they emerge |
| CA certificate distribution | Fetched separately and checked against an out-of-band fingerprint | Delivered directly over the authenticated TLS session |
| Renewal | Supported, but through polling (submit a renewal request, then poll for the result) | Supported natively over an already-authenticated mTLS session |
| Where it tends to show up | Older or simpler network devices, many existing vendor implementations | Newer equipment and anything that needs stronger authentication or algorithm flexibility |
Enrolling devices with EST and SCEP
For actually getting certificates onto devices, the Avassa Edge Enforcer supports both EST and SCEP, the two protocols most network equipment already speaks. That support can be wired up in a couple of ways: through an intermediary like Cisco ISE, or directly to any device capable of EST or SCEP on its own. Either way, you’re not forcing vendors’ equipment into a workflow it wasn’t built for.
Certificates for applications, not just devices
Network equipment isn’t the only thing that needs an identity. The applications running on top of it, the workloads doing the actual data processing at each site, need client and server certificates too, and Avassa handles that side of things through Strongbox, its built-in secret vault.
Strongbox can issue certificates directly or request one from your existing CA. Certificates are treated as vault secrets and referenced right in the application manifest, so when an application is deployed, the platform mounts the certificate files into the container automatically. The certificate follows the application: wherever it’s deployed, whatever site it lands on, it shows up with the right certificate already in place, no separate provisioning step required.
Renewal works the same policy-based way as the rest of the system. You set a TTL and a renewal threshold, for example a 30-day CA that auto-renews with 5 days left, and Strongbox handles the rotation without anyone needing to intervene. That makes genuinely short-lived certificates practical for application workloads too, not just network devices.
Because the policy is defined once and applies wherever the application runs, this scales the same way across a handful of sites or several thousand: one configuration, distributed automatically, rather than something that has to be managed site by site.
The hard part: short-lived certificates and disconnected sites
Short-lived certificates are good security practice. They limit the damage window if a key is ever compromised, and they reduce reliance on revocation lists that devices may not check reliably anyway. But short-lived certificates only work if renewal is reliable, and that’s where edge networking gets tricky.
A piece of network equipment at a remote site can lose its connection to the central network for reasons that have nothing to do with security: a fiber cut, a power outage, a misconfigured upstream router. If a certificate is set to expire in, say, 24 hours, and the site is cut off for 36, you’re suddenly looking at devices that can no longer authenticate, right when you probably need them working.
This is the real challenge in PKI for network devices: keeping certificate lifetimes short enough to be meaningful from a security standpoint, while making sure a disconnect doesn’t turn into an outage. Avassa’s approach handles this through automatic renewal well ahead of expiry, so devices aren’t waiting until the last minute to request a new certificate, combined with enrollment and renewal logic that’s resilient to the kind of intermittent connectivity edge sites actually experience. Secondly, the Edge Enforcer is fully functional even in offline scenarios and will keep serving both applications and network equipment with fresh certificates.
What else is in the box?
Beyond enrollment and renewal, the same system covers the rest of the certificate lifecycle you’d expect from a production-grade PKI setup:
- Revocation, so a compromised or decommissioned device can have its trust pulled, via CRL and OCSP.
- Zero-touch provisioning, so a new device can bootstrap trust and receive its first certificate without someone manually walking through setup at each site.
- Multi-site and multi-tenant support, so distinct CA trust chains can be managed per site or per customer as your footprint grows.
- Audit and visibility, so you can see certificate status, expiry, and enrollment history across the whole fleet from Control Tower, rather than piecing it together site by site.
Why this matters
PKI for network devices tends to get treated as a checkbox: EST or SCEP, done. But the operational reality, thousands of devices, unreliable links, short certificate lifetimes, is where most implementations quietly fail. The goal with Avassa’s approach is to make short-lived certificates practical at the edge, not just possible in a lab.