Network automation is no longer optional, and every automated network is driven by APIs: RESTCONF on the routers, the Catalyst Center intent API, the SD-WAN Manager API, cloud provider APIs. Each of those is a new door into your infrastructure, and a door that a script can walk through is a door an attacker can walk through. The security of your automation is the security of your network, and it is a topic the CCNP blueprint now expects you to reason about.
This article covers the security principles for the network APIs you will actually use, framed for network engineers rather than web developers. It extends the Infrastructure Security cluster guide and pairs with the automation work in the Network Automation cluster.
Why This Is a Security Problem Now
The old management plane was a human typing into an SSH session, protected by AAA and a VTY ACL. The new management plane is a token in a script hitting a REST endpoint, and it changes the threat model:
First: TLS, Always
Every API call must go over TLS (HTTPS). This is non-negotiable and yet routinely violated in labs and even production, because the quick way to make a script work is to disable certificate verification when the device presents a self-signed cert.
You will recognise this pattern, and you should treat it as a red flag:
# NEVER in production
requests.get(url, verify=False) # disables cert verificationverify=False turns HTTPS back into a channel any man-in-the-middle can read and modify. The correct fixes: install the device's certificate into your trust store, or run an internal CA and have your devices present certs signed by it, then verify against that CA. On IOS XE, the RESTCONF/NETCONF endpoint uses the device's SSH/HTTPS key material, and you can replace the default self-signed certificate with one from your PKI. Effort now, versus an undetectable compromise of your automation channel later.
Tokens, Not Passwords
Most modern network APIs (Catalyst Center, SD-WAN Manager, Meraki) use token-based authentication: you authenticate once with credentials, receive a short-lived token, and use that token on subsequent calls. This is strictly better than sending a username and password on every request, for reasons worth understanding:
The corollary: treat the token like a live credential. Do not log it, do not print it, do not commit it. Request it, hold it in memory, use it, let it expire. A token in a CI job's console output is a credential in a place many people can read.
Never Hardcode Secrets
The single most common real-world API security failure is a credential committed to a git repository. It is so common that automated bots scan public repos for API keys within seconds of a push. The discipline:
- Environment variables for local scripts, never literals in the code.
- A secrets manager (HashiCorp Vault, AWS Secrets Manager, Ansible Vault) for anything beyond a personal script. The script requests the secret at runtime; it is never at rest in the code.
- A .gitignore that excludes credential files, and pre-commit hooks that scan for secrets before they can be committed.
- Rotate anything that leaks. A credential that was ever in a repo, even in deleted history, is compromised. Rotate it; do not just remove the file.
This is not paranoia. Leaked network automation credentials are a documented, routine attack vector, precisely because they combine high privilege with poor hygiene.
Least Privilege for Service Accounts
The account your automation uses should have exactly the permissions it needs and nothing more. A monitoring script that only reads interface stats needs read-only access; giving it a privilege-15 write-capable account "so it works" is how a bug or a compromise becomes a network-wide outage.
Concretely, using the AAA infrastructure from the AAA article:
- Create a dedicated service account per automation system, never shared with humans.
- Scope it with TACACS+ command authorization or an API role to only the operations it performs.
- Restrict where it can connect from (a management ACL permitting only the automation host's address, as covered in management-plane hardening).
- Enable accounting so every API-driven change is attributable to that service account, giving you an audit trail.
Read the Response Codes
Security is not only about the request; it is about noticing when something is wrong in the response. An automation pipeline that ignores HTTP status codes will happily continue after an authentication failure or a partial change, and that silence is dangerous. The ones that matter for security:
These codes, and how to handle them in a script, are covered in depth in the automation cluster's REST API response codes article. From a security angle the rule is simple: never let a pipeline plough on after a 401 or 403. That is the moment to stop and alert.
The Practical Checklist
verify=False in production.FAQ
Is disabling certificate verification ever acceptable?
Only in a throwaway lab you fully control and that carries no real credentials. The moment a real token crosses that connection, verification must be on. The habit of verify=False is dangerous precisely because it works, so it survives into production.
Where should I store API tokens?
In memory for the life of the script, requested at runtime from an environment variable or secrets manager. Not on disk, not in the code, not in logs.
What is the difference between 401 and 403?
401 means "I do not know who you are" (bad or missing token). 403 means "I know who you are, and you are not allowed to do this" (authenticated but unauthorized). The fix differs: re-authenticate for 401, check your role for 403.
Do I need a secrets manager for a small script?
For a personal, local script, environment variables are an acceptable minimum. For anything shared, scheduled, or in CI, use a real secrets manager. The line is "will this credential ever exist somewhere another person or system can read it."
How does this relate to RESTCONF on my routers?
Directly. RESTCONF is a REST API on the device, and every principle here applies: TLS with a real certificate, authenticated access, least privilege, and handling the response codes. See the automation cluster for the hands-on RESTCONF walkthrough.
Key Takeaways
- APIs are the new management plane, and a compromised automation credential has a blast radius of the entire network, not one device.
- TLS always, verify certificates.
verify=Falseis a red flag that turns HTTPS back into cleartext. - Prefer short-lived, revocable, scoped tokens over per-call passwords. Never log or commit them.
- Never hardcode secrets. Use environment variables or a secrets manager, exclude them from git, and rotate anything that leaks, including from deleted history.
- Give automation dedicated, least-privilege service accounts, source-restricted and accounted for.
- Handle response codes: stop on 401/403, back off on 429, and never let a pipeline continue blindly after an auth failure.
Next: hardening the management plane, or the Infrastructure Security cluster guide.
