Notifications
Clear all
Topic starter
08/06/2026 5:00 pm
TL;DR: Software-defined networking separates the control plane from the data plane so network policy can be programmed centrally, improving visibility, scalability, and policy propagation while creating controller-level concentration risk, according to StrongDM. For identity teams, the lesson is that centralisation helps only when access, assurance, and monitoring are designed to fail safely.
NHIMG editorial — based on content published by StrongDM: Software-Defined Networking Explained | 2026 SDN Guide
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams govern a software-defined network controller?
A: Security teams should govern the controller as a privileged orchestration layer, not a routine admin console.
Q: Why does SDN change how teams think about visibility and trust?
A: SDN changes visibility because the control plane becomes software-driven and centralized, but that does not guarantee full operational insight.
Q: What breaks when SDN policy propagation is not tightly governed?
A: What breaks is consistency.
Practitioner guidance
- Classify the SDN controller as a privileged control surface Assign explicit ownership, restrict admin pathways, and log every policy change that can affect segmentation, routing, or service reachability.
- Correlate controller output with workload telemetry Do not rely on the network controller alone for visibility.
- Review automation identities that push network policy Map the service accounts, tokens, and CI/CD identities that can modify SDN state.
What's in the full article
StrongDM's full article covers the architectural detail this post intentionally leaves at the control and governance level:
- A plain-language walkthrough of control plane, data plane, northbound interface, and southbound interface behavior
- Side-by-side comparisons with VPN, NFV, and traditional networks for infrastructure planning
- A practical example showing how Tribune Media moved more than 140 applications onto SDN infrastructure
- A review of the trade-offs around visibility, latency, upfront cost, and staffing
👉 Read StrongDM's guide to software-defined networking architecture and trade-offs →
Software-defined networking and access control: what changes for IAM teams?
Explore further
08/06/2026 6:56 pm
Software-defined networking is an identity problem as much as it is a networking model. Once policy moves into software, the controller becomes a privileged decision point that resembles other identity control surfaces, including PAM brokers and access orchestration layers. That makes governance, auditability, and change discipline more important than the hardware abstraction itself. Practitioners should treat SDN as part of the access control stack, not just the transport stack.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
A question worth separating out:
Q: How do IAM and NHI teams fit into software-defined networking governance?
A: IAM and NHI teams should map which identities can change SDN state, which secrets authorise those changes, and how those privileges are reviewed over time. That includes automation accounts used by orchestration tools and the humans who approve changes. The key is to govern the identities behind the network, not only the devices in it.
👉 Read our full editorial: Software-defined networking shifts control, visibility, and access
