A Walk Through Cisco SDSI (and Where Network Security Is Headed in 2026)
I spent a couple of weekends going through the Cisco 300-745 SDSI (Designing Cisco Secure Infrastructure Solutions) material, and I came away with a clear takeaway: this is less an exam blueprint and more a checklist for network design and architecture. Most certs teach you to configure a feature. SDSI keeps asking a harder question: given this business, this threat model, and these constraints, what should the architecture be?
A quick note on how I got here: Cisco is offering this course free for a limited time on Cisco U, and I took advantage of that. There was a practical reason beyond curiosity. The Learning Path earns 41 Continuing Education (CE) credits. Those credits are valuable for renewing my CCNP certifications later on, so a free, design-level course that also covers a big chunk of a recertification cycle was not something I was going to pass up . If the offer is still running when you read this, it is well worth grabbing.
So this is my walk through the six SDSI domains. I am not going to repeat the blueprint line by line. Instead I want to cover each area briefly, add a real example from networking and security, and connect it to where the industry is moving in 2026. Along the way I will link back to a few things I have already written here, because a lot of the SDSI theory maps directly onto problems I already talked about before in this blog.
This one runs long, so settle in and grab some coffee.
What SDSI actually is
SDSI sits in the CCNP Security track as a design-focused exam. The key word is design. You are expected to look at requirements, regulatory constraints, and a threat landscape, then justify an architecture. The material is split into six modules:
- Security Architecture Design Fundamentals
- Security Architecture for Infrastructure Protection
- Firewall Technologies and Advanced Security Solutions
- Application Security and Secure Data Flow
- Risk Management and Incident Response Strategies
- DevSecOps Integration and Automated Security Pipelines
The modules build on each other the way a real design conversation does. You start with principles, move to the infrastructure, lock down the choke-points, follow the data, plan for when things go wrong, and finally build security into how software ships. Let me take them one at a time.
Module 1: Architecture fundamentals
The first module is foundations: defense in depth, least privilege, zero trust, encryption, secure-by-design, and the frameworks that structure those ideas (MITRE ATT&CK, CAPEC, the NIST Risk Management Framework, and SASE).
The case study that opens the module is one I have seen more than once: migrating from a flat network to a layered design. A flat network feels great on day one. Everything reaches everything, nothing is blocked, the help desk is quiet. Then someone clicks a phishing link, and the same flatness that made setup easy lets ransomware spread to everything at once. There is no friction, so there is no containment.
This is where the SDSI principles stop being abstract. Least privilege and segmentation are not separate features you bolt on. They are the same idea at different layers. When I wrote up network segmentation best practices and securing the management plane, the main point was that the management plane is the most valuable target, and a flat network hands an attacker your servers and your switches at the same time. SDSI puts structure on that instinct with the defense-in-depth model: physical, network, application, and data layers, each one assuming the layer in front of it has already failed.
Zero trust gets used as a marketing word, so I liked that SDSI treats it as a design discipline, not a product. The core idea is to replace implicit trust ("you are inside the perimeter, so you are fine") with continuous verification of identity, device posture, and context. In practice you almost never replace the old model in one weekend. You migrate. You pick the highest-risk access path, put real verification in front of it, and expand from there.
The framework worth flagging for anyone designing today is SASE (Secure Access Service Edge). SDSI introduces it as the convergence of networking and security into a cloud-delivered model: SD-WAN, secure web gateway, CASB, NGFW, and zero trust network access in one place. This matters more in 2026 than when the cert content was written, and I will come back to it, because Gartner's market research numbers on SASE adoption are worth a look.
Module 2: Infrastructure protection
Module 2 is the biggest of the six, and for good reason. It covers endpoint and client security, identity and access management, two-factor and passwordless authentication (Cisco Duo features heavily), email security, securing hybrid workers, IoT, SaaS, multi-cloud, network access security (802.1X, MAC Authentication Bypass, WebAuth), VPN and tunneling, SD-WAN, and securing the management and control planes.
If you read that list and thought the common thread is identity, you read it the way I did. Once the perimeter dissolves, identity is what you are actually defending. The passwordless section is the part I enjoyed most, because it lines up with two articles I wrote on identity hardening: device-level IAM and then single sign-on with Authentik. SDSI walks through the user-experience and implementation challenges of going passwordless, and they are the same ones I hit. Passwordless is great until you have to design the fallback path, the device-loss recovery flow, and the legacy app that still wants a password. The hard work is in the edge cases, not the happy path.
The network access control section (802.1X, MAB, WebAuth) is the usual Cisco ISE territory (or Aruba clearpass if you're not a Cisco shop), and the design activities are practical: a phased 802.1X rollout across an enterprise, MAB plus profiling for an IoT-heavy environment, and WebAuth for BYOD and guest access at a financial institution. The repeated lesson is that you cannot authenticate what you cannot identify. A camera, a badge reader, and a label printer will never speak 802.1X, so you profile them and fall back to MAB, and you accept that this is a weaker control that needs segmentation around it.
On the VPN and tunneling side, the module covers remote-access VPN, WAN connectivity, and SD-WAN with cloud-based tunnels. If you want the detailed version of why these technologies behave the way they do, I went through the mechanics in the architecture of VPNs, overlays, and IPsec. And for the small-footprint, zero-trust version of remote access that a homelab or small team can run, I wrote about secure remote access with Tailscale connectors. Tailscale is basically a small-scale version of the same identity-driven, encrypted-overlay model that SASE sells to the enterprise.
Securing the management and control planes closes the module, and I am glad SDSI ends there instead of treating it as an afterthought. The control plane is how your network decides where packets go. Compromise it and the data plane does whatever the attacker wants. This is why In this blog I keep talking about management-plane isolation: out-of-band management, hardened admin access, and locked-down protocols are not optional polish. They are the difference between an incident and a disaster. My FortiGate guide to hardening administrative access is the hands-on version of this section.
Module 3: Firewalls
Module 3 is the one that feels most familiar if you have run a firewall in production. It covers next-generation firewalls and how they differ from traditional ones, web application firewalls, IPS and IDS deployment, and host-based and distributed firewalls.
The NGFW versus traditional firewall difference is worth stating plainly because people blur it. A traditional firewall decides on ports and addresses. An NGFW adds application awareness, user identity, and built-in threat inspection, so a rule can say "this user group may use this application" instead of "this subnet may reach this port." That sounds like a small step until you try to write a sane policy for modern SaaS, where everything is port 443 and the port tells you nothing.
The firewall objects and segmentation activities map almost one to one onto my FortiGate series. For the practical foundation, Part 1 covers the essential firewall objects for a hardened perimeter, and Part 2 is the network segmentation build itself. SDSI's "malware lateral movement in the data center" activity is the design version of the same segmentation problem I discussed before with VLANs, zones, and policy on a fortigate appliance box.
The IPS and IDS section deserves a callout for one feature: virtual patching. SDSI describes IPS as inline inspection that drops traffic matching known exploit signatures before it reaches the target. That is the mechanism I used in FortiGate virtual patching, where the firewall's IPS engine protects a service you cannot patch yet, including the firewall's own management and VPN interfaces. Virtual patching is one of the most underrated compensating controls there is, and it comes back in Module 5 as exactly that.
The host-based and distributed firewall section is the bridge to the cloud-native world. A distributed firewall pushes policy down to every workload, which is how you segment when there is no longer a single choke-point to put a box in front of. Similar shift I covered in Docker networking, bridge versus macvlan for segmented environments. Once your workloads are containers that start and stop in seconds, segmentation has to be policy that travels with the workload.
Module 4: Application Security
Module 4 shifts from "where is the traffic" to "what is the traffic and where is the data going." It covers application firewalls, SSL offloading and decryption, data loss prevention, endpoint security in the data flow, DNS security, then cloud-native and microservices security, containers and Kubernetes, serverless, and the emerging-tech pair of generative AI and quantum computing.
The SSL decryption section forces an honest conversation every time. Most traffic is encrypted now, which is good for privacy and hard for inspection. You cannot inspect what you cannot read. So you either decrypt at a choke-point and accept the privacy, performance, and certificate-management costs, or you stay blind to a growing share of your traffic. SDSI puts this design activity in a privacy-conscious environment on purpose, because the right answer is rarely "decrypt everything." It is a deliberate choice: decrypt what policy and law allow, skip what you must (banking, health), and document why.
DNS security is the quiet win of this module. DNS is the first thing almost every connection does and one of the cheapest places to enforce policy, which is why DNS-layer defense (Cisco Umbrella in the Cisco world) shows up as a design pattern for hybrid and remote workforces. Blocking a malicious domain at resolution time stops a threat before a single packet reaches the payload server. It is high value for low cost, and it works for users who are nowhere near your network. In a homelab, DNS security is rather an easy and fun implementation with Pi-Hole or even better with Technitium which we will also cover at some point in the near future on this blog, Stay tuned for that ;)
The Kubernetes and container security section is where my homelab work and the cert content lined up most directly. SDSI covers microservices segmentation, container and Kubernetes security, and serverless. I have been writing a whole Kubernetes series on exactly this, including TLS and secrets management with cert-manager and Sealed Secrets. If you want to understand why containers need their own security model in the first place, I also wrote Linux containers demystified, which digs into the namespaces and cgroups that make a container a container, and therefore where its security boundaries actually are.
The emerging-tech section closes the module with generative AI and quantum computing. The cert content names the threats; 2026 has turned them into board-level priorities. More on that below, because post-quantum cryptography and agentic AI are now two of the loudest items on every analyst's list.
Module 5: Risk management and the assumption that you will get hit
Module 5 is the practical one. It covers SOC tooling (SIEM, SOAR, network observability, and eBPF), risk management frameworks, compensating controls, the Cisco SAFE framework, and incident-driven design changes for APTs, DDoS, ransomware, and insider breaches.
The mindset shift is the valuable part. The first four modules are about prevention. This one assumes prevention will eventually fail and asks what your design does next. That is the difference between security theater and resilience.
A few things stood out. SIEM and SOAR are treated as a pair: the SIEM correlates and surfaces events, the SOAR automates the response so a human is not copy-pasting indicators at 2am. eBPF gets its own section, and rightly so, because it has become the backbone of modern observability and runtime security. Seeing and enforcing policy in the kernel without clunky agents is a real step up from what we had a few years ago.
Compensating controls are the most useful concept here for day-to-day design. The legacy banking system that cannot be patched, the OT device that will never run an agent, the application that needs a protocol you would rather kill. You cannot fix these, so you wrap them. Segmentation, virtual patching, tighter monitoring, and strict access become the controls that make up for the risk you cannot remove. This is real-world architecture, where "just patch it" is often not an option and the design has to deal with that.
The incident-response activities are where the module pays off, and the ransomware one hits closest to home. Recovery is a design choice, not an improvisation. If your backups are reachable and writable from the same network that got encrypted, you do not have backups, you have more victims. I built my own answer to this in Kubernetes backups and disaster recovery: three layers, three failure modes, and the through-line is the same as SDSI's: design for the failure mode, isolate the recovery path, and test that you can actually come back.
Module 6: DevSecOps
The final module is DevSecOps: securing the CI/CD pipeline, automated vulnerability scanning, API security, automated security testing for continuous compliance, infrastructure as code for security, security telemetry, and a long list of AI-assisted security design tasks (threat modeling, secure code review, policy writing, red-team scenario design, and more).
The central idea is that security has to move at the speed of deployment, which means it has to be code. A manual security review that happens once a quarter means nothing when you ship twenty times a day. So the controls become pipeline stages: scan the dependencies, scan the image, scan the infrastructure-as-code template, and fail the build if something is wrong.
This is the module where my own work and the cert content are closest, because GitOps is this idea made concrete. When I wrote GitOps with Flux, deleting the "works on my cluster" problem and later deploying an app the GitOps way, the security payoff was almost a side effect of the workflow. When the git commit is the deployment, you get an audit trail for free, you get peer review for free, and you can revert a bad change in one command. Infrastructure as code is not just convenient. It is what makes continuous compliance possible, because you can scan and check a YAML file in a way you can never check a human clicking through a console.
The AI-assisted design tasks at the end of the module read as ahead of their time. SDSI has you practice using AI to help with threat models, code review, and incident-response simulation. A year ago that looked forward-looking. In 2026 it is becoming a reality, which brings me to the part of this article I am most interested in.
Where this is heading: the 2026 picture
Here I want to step back from the blueprint and look at the market, because a design framework is only as good as its fit with the current threat landscape. I went through the recent analyst material, and a few themes are hard to ignore.
Gartner published its top cybersecurity trends for 2026, and three of the six are basically the same problem in different forms: autonomous AI running inside the enterprise without enough governance. The stat that stood out, from the same research, is that in this new mixed workforce, machines and agents already outnumber human employees by roughly 82 to 1!! Sit with that. Every IAM decision you make for humans now has to be made, at much larger scale, for non-human identities that can act on their own.
Let me connect the headline trends back to the SDSI modules, because the mapping is clean.
Agentic AI oversight and IAM for AI agents. This is Module 2's identity problem, multiplied. SDSI teaches you to govern identity, posture, and context for users and devices. In 2026 the same discipline has to cover AI agents that register themselves, hold credentials, and call APIs on their own. The questions are familiar (who is this identity, what may it do, how do we revoke it) but the answers have to be automated, because you will never hand-manage thousands of machine actors. If you are building anything with autonomous agents, treat each one as a privileged service account from day one, not as something you will secure later.
Post-quantum cryptography. Module 4 names quantum as an emerging risk. Gartner now frames 2026 as the start of the largest and most complex cryptographic migration in history, driven by government mandates and the "harvest now, decrypt later" threat, where attackers record your encrypted traffic today to decrypt it once quantum computers mature. The takeaway is crypto-agility. You want an architecture where you can swap algorithms without rebuilding everything, which means knowing where your asymmetric crypto lives, including places you forgot about like VPN tunnels, certificate chains, and that one legacy appliance. This is the SSL and tunneling content from Modules 2 and 4 with a deadline attached.
AI-enabled SOCs. This is Module 5 evolving in real time. SIEM and SOAR are merging with AI that triages alerts and drafts response actions. The promise is relief from analyst burnout and alert fatigue; the risk Gartner flags is new complexity, upskilling pressure, and cost surprises. My read is that the principle does not change. The SOC is still correlate, decide, respond. AI just speeds up the loop, and you still need humans owning the decisions that matter.
Adaptive security awareness. Gartner's survey found that over half of employees use personal generative-AI accounts for work and a third admit feeding sensitive data into unapproved tools. That is a data-loss-prevention problem (Module 4) and a people problem at once. The response is not another annual training video. As you may already know DLP is needed to solve the AI leakage issue, and My read on this is that I think we still do not have proper solutions to account for data leakage with personal AI agents. The solutions that exist are not as mature and to me it seems that the industry is still trying to figure this one out.
On the networking side, the SASE story is the one I would bet on hardest. Gartner notes that single-vendor SASE adoption is climbing fast, with a large share of new SD-WAN purchases expected to be part of a single-vendor SASE offering, up from a small fraction a few years ago. Read alongside the Hype Cycle commentary that SASE has moved from a "nice to have" to a critical framework, the direction is clear. The branch-office firewall and the standalone VPN concentrator are being folded into an identity-driven, cloud-delivered edge. SDSI's Module 1 introduction of SASE is not theory anymore. It is the default architecture conversation for any new design in 2026.
So how does this change how you design a network?
If I boil everything above down to the design moves I will actually carry into my next project, it looks like this.
Start from identity, not from subnets. The perimeter is mostly gone. Design the access model first (users, devices, and increasingly agents), and let the topology serve it. This is SDSI Modules 1 and 2 combined with the 2026 reality that non-human identities dominate.
Segment as if you have already been breached. Flat is the enemy. Every segment boundary is a place where you can contain a problem. Whether it is VLANs and FortiGate zones at the edge or distributed policy inside a Kubernetes cluster, the principle is the same: assume lateral movement and make it expensive.
Make the management and control planes the most boring, locked-down part of the network. No internet exposure, hardened admin access, out-of-band where possible. This is the cheapest insurance you can buy.
Push security into the pipeline. If your controls are not code, they will not keep up with how fast software ships. GitOps and IaC (infrastructure as code) turn compliance into something you can actually enforce and audit.
Design for recovery, not just prevention. Backups that share the same blast radius are not backups. Build the recovery path as carefully as the prevention controls, and test it.
Start on crypto-agility and AI-identity governance now. These are the two slow-moving problems of 2026. Post-quantum migration and machine-identity sprawl will both take years, and the organizations that start early will be the ones not scrambling later.
Closing thought
What surprised me most about SDSI is how little of it is about a specific Cisco product and how much of it is about judgment. The frameworks (MITRE ATT&CK, NIST RMF, SAFE, SASE) are scaffolding for a way of thinking: understand the business, model the threat, layer the defenses, follow the data, and plan for the day it all fails. The product names will change. Cisco Duo, Umbrella, ISE, and Secure Firewall are the examples in the courseware, but the design reasoning transfers cleanly to a FortiGate, a Kubernetes cluster, or a cloud-native stack you build yourself.
That is why so much of the material lined up with things I had already worked through here, from FortiGate hardening to GitOps with Flux to disaster recovery in Kubernetes. The cert teaches you the vocabulary and the structure. The homelab teaches you the practice. The 2026 trends are the same principles meeting a faster, more autonomous, and more adversarial world.
If you are studying SDSI yourself, my advice is to skip the memorizing and argue with the design activities instead. Pick a different answer than the one you first reach for, and defend it. Start Practicing the secure design concepts in your home network and your home devices, Cisco Duo has a free tier, pfSense can be deployed on a box, Proxmox is easy to homelab, Create a Github account and try to use it.
Additionally, feel free to grab my summary notes on the SDSI course here on my github page.
If you found this useful, the practical companions to several sections above are here on the blog: the FortiGate best-practices series, the Kubernetes home-cluster series, and the GitOps with Flux write-up.