Debunking the Myths of Cisco's Software-Defined Access (SDA)

Myth #1: SDA is too buggy

Yes, early versions of SDA had their share of growing pains. But that was almost a decade ago, when the technology was being pioneered. Today, SDA is a stable, production-grade solution deployed across thousands of campuses globally.

Cisco has invested heavily in refining the architecture, improving software quality, and enhancing operational workflows. With each release, the bugs have been squashed and the platform has become more resilient and predictable. In fact, an inside source within the Cisco BU tells us that SDA is down to less than 6% of TAC cases involving software defects/bugs.

Case Study: Fiona Stanley Hospital
Fiona Stanley Hospital (Australia) deployed SDA across two data centers, 15,000+ switch ports, and 2,200 access points. By reducing the number of required protocols from over 30 to just 3, SDA enabled campus-wide Layer 2 stretch, decreased subnet count and improved overall network efficiency. The result: optimal resource utilization and streamlined operations for critical healthcare services.

Myth #2: SDA is a fad that will pass

Far from it. SDA represents a fundamental shift in how campus networks are designed and operated. Cisco pioneered the concept of a campus fabric, and now nearly every major OEM (HPE Aruba, Juniper, Arista, Fortinet, Extreme) has introduced its own version of a fabric-based campus solution. Why? Because the benefits are undeniable: simplified operations, consistent policy enforcement, enhanced resiliency, and scalable segmentation. Campus fabric turns out to be the "desired state" of most organizations that I am having conversations with these days.

Case Study: Yale University

Yale University deployed Cisco SDA to modernize its campus network, supporting research, education, and healthcare across diverse environments. SDA enabled unified wired and wireless policy, automated provisioning and secure segmentation for students, faculty, and medical staff. The solution simplified operations, improved visibility, and enhanced security posture, which established the foundation for a resilient, scalable and intelligent campus fabric aligned with Yale's innovation-driven mission.

Myth #3: SDA is too complex 

Complexity is relative. Traditional campus designs with VLAN sprawl, manual ACLs, and inconsistent policy enforcement are arguably more complex than SDA. With SDA, complexity is abstracted through automation and intent-based workflows in Cisco Catalyst Center (formerly DNAC). Network admins can deploy segmentation, onboard devices, and manage policies through intuitive GUIs and templates. I would argue to say that SDA simplifies what used to be manual and error-prone.

Case Study: Kempegowda International Airport 
Kempegowda International Airport (Bangalore) migrated to SDA, supporting 41 million passengers per year, 36 airlines, and 15,000 workers. Thanks to automation, segmentation, and centralized management, the fabric is operated by a mere four-member team. The airport saw a 50% reduction in support tickets, a 60% reduction in VLANs, and significant improvements in network uptime and performance.
 

Myth #4: SDA is not ready for production

This myth is simply outdated. SDA has been in production since around 2017 and is now deployed in large enterprises, universities, hospitals, and government agencies. Not only is it "ready," but it has been thoroughly battle-tested. Cisco's reference architectures, validated designs and extensive documentation make it easier than ever to deploy SDA with confidence.

Case Study: Sanford Health

Sanford Health deployed Cisco SDA to modernize its healthcare network across hospitals and clinics, supporting thousands of medical devices and users. SDA enabled identity-based segmentation, automated policy enforcement and unified wired/wireless access, ensuring secure and reliable connectivity for clinical applications. The solution improved operational efficiency, reduced manual configurations and enhanced patient data protection—critical for compliance and care delivery in a highly regulated healthcare environment.

Case Study: GlobalFi
A Global Bank manages over 10,000 devices, 50,000+ users, and 1200+ fabric sites with SDA. A team of just five manages this massive scale, leveraging intent-based networking, automation, and centralized policy enforcement. The bank achieved operational gains including 50%+ reduction in admin effort, 40% faster service provisioning and 70% improvement in network issue detection.

Myth #5: SDA is another security/segmentation tool 

Network segmentation is another desired state we constantly hear from our customer base. SDA did not create any new technology or protocol in this case, but what it brings to the table regarding segmentation is the vehicle to fully automate the implementation of an organization's segmentation strategy. The strategy will likely utilize the traditional concepts of VLANs, VRFs and SGTs, but now it can be standardized across sites and deployed at scale.

On day one, turnkey automation solutions that allow for end-to-end macro segmentation with literally a checkbox for the sites that you do or do not want these segments to exist can be accomplished.  Secondly, 802.1x is fully automated and deployed to switches without the need to develop any of the configuration.  The policies themselves still need to be configured in the chosen NAC platform because policies will vary from one organization to the next, yet the most complicated part is handled completely under the hood.

Case Study: Toyota Motor North America

Toyota Motor North America adopted Cisco SDA to unify its IT and OT networks across manufacturing and enterprise environments. The deployment enabled identity-based segmentation, consistent policy enforcement, and seamless integration of wired and wireless infrastructure. With automation at scale, Toyota improved operational efficiency, enhanced visibility and reduced risk across thousands of endpoints. The solution supported secure connectivity for industrial systems and streamlined network operations, aligning with Toyota's smart manufacturing goals.

Myth #6: DNA = DNAC = SDA

This is a common misunderstanding, and the terminology is often used interchangeably.  However, a distinction between these terms certainly exists and is worth pointing out:

1. DNA stands for "Digital Network Architecture," which is essentially an umbrella term that covers many different domains within the modern Cisco portfolio.
2. DNAC, which has been rebranded as "Catalyst Center", is the orchestration and management platform that consists of many applications and operational tools across the four pillars of enterprise networking: NetOps, SecOps, DevOps and AIOps.
3. SDA is the acronym for "Software-Defined Access," sometimes also referred to as "SD-Access". This term includes the campus fabric portion of the suite, which consists of the LISP control plane, the VXLAN data plane and the fully automated provisioning of this fabric by the orchestration platform mentioned above. This is one of the applications within the NetOps pillar that is managed from Catalyst Center.

Case Study: Buckinghamshire Council (United Kingdom)

Buckinghamshire Council implemented Cisco SDA as part of its "One IT" transformation program, aiming to unify and modernize its IT infrastructure across more than 250 locations, including schools, hospitals, council offices and fire stations. The council serves over 500,000 residents, and needed a secure, scalable and centrally managed network to support critical public services.

By deploying Cisco SDA, the council achieved:

• Unified network fabric across diverse sites.
• Centralized policy enforcement using Cisco Identity Services Engine (ISE).
• Improved security and segmentation, ensuring sensitive data and services are isolated appropriately.
• Operational simplicity, reducing the burden on IT teams and enabling faster service delivery.

This deployment highlights how SDA can support large-scale, multi-site public sector environments with high security and reliability requirements.

Myth #7: SDA is built on proprietary protocols

Nope. SDA leverages open standards like BGP, IS-IS, VXLAN and LISP (yes, LISP is an open standard: RFC 9300). While Cisco's implementation may include proprietary extensions for optimization, the core technologies are standards-based and interoperable. SDA and Catalyst Center are not a closed system. Hundreds of 3rd Party applications are supported, and thousands of API's are open, NetDevOps and CI/CD operational models. But does it matter?  Is Cisco the only OEM guilty of "creating" a protocol to implement a solution?  Furthermore, does proprietary equate to "vendor lock-in", or does it provide evidence of innovation?

To illustrate why this "myth" is potentially a moot point anyway, the following table covers a few other protocols out there in production that should look familiar. Each of these found their origin, early development and early adoption within the Cisco laboratories. 

Call to action: Time to shift the mindset

The days of manually stitched networks, sprawling VLANs, and reactive troubleshooting are over. Campus fabric offers a more intelligent, secure, resilient and operationally efficient way to build and manage campus networks. To properly guide our customers through this journey, we all have to transform and "modernize" our thinking about networking.

Let's move beyond legacy limitations. Embrace the fabric. Embrace the future…which is achievable today!

References

SD-Access Success Stories

Transforming Enterprise Networks with Cisco SD-Access