Security Architecture in an AI and Quantum World: My Conversation with 2GuysTek

It was great to sit down with Rich from 2GuysTek to discuss Cybersecurity Architect's Handbook, Second Edition and compare our perspectives on security as it exists today. The conversation also gave us room to look ahead at the future of cybersecurity in a world increasingly shaped by AI and, eventually, quantum computing.

We talked about the book, but the conversation reached well beyond it. AI-assisted vulnerability discovery, software supply chains, zero trust, quantum readiness, legacy technology, burnout, and the realities of working inside a business all made their way into the hour.

Lester Nichols and the Cybersecurity Architect's Handbook

Rich works in infrastructure and security engineering when he is not making virtualization and homelab videos. That made this a practitioner-to-practitioner conversation. He understood why the details matter, but he also kept bringing the discussion back to the people who have to learn, build, operate, and defend these systems.

The full interview is available on YouTube. The video is not sponsored. I sent Rich a copy of the book with no conditions attached, and he invited me onto the channel after reading it. You can also listen on the 2GT Podcast.

If you want to jump to a particular part of the conversation:

Why I wrote the book

We started with the path that took me from pre-med studies into information technology and eventually cybersecurity. One of my earliest experiences at the intersection of technology, business, and investigation came from building a Microsoft Access database for an anesthesiologist. The reporting exposed irregularities in the billing records. That project was a practical lesson in something I would encounter repeatedly: technology can make a business problem visible, but someone still has to recognize what the evidence means and act on it.

My career then moved through database administration, network engineering, and security. That progression shaped the book. Security architecture does not sit apart from networking, operating systems, applications, identity, cloud platforms, risk, finance, or organizational behavior. An architect has to understand how those pieces affect one another.

I wrote the first edition because I saw gaps on both sides. Many IT practitioners did not fully understand what security teams were trying to accomplish. Security practitioners could become so specialized that they lost sight of adjacent disciplines. I wanted to create a resource that connected those areas and helped people develop as architects rather than memorize an isolated set of controls.

The second edition is a rewrite, not a light update

Rich asked what changed in the second edition. The second edition is much more than a light update.

Feedback on the first edition was consistent: readers wanted more depth. The original moved quickly. For the second edition, I rewrote every chapter, removed duplication, expanded subjects that needed more treatment, and added material covering AI security and several industry contexts. I also pushed to retain the foundational opening chapters when the publisher proposed cutting them. Those chapters establish the common baseline the rest of the book depends on. Removing them would have saved pages while weakening the reason the book exists.

The published book, labs, and supplemental material together approach 1,400 pages. The size is a consequence of trying to connect architectural thinking to work a reader can perform. The labs no longer stand alone as unrelated exercises. They build from a secure lab foundation through containerization and security tooling, then culminate in an AI-assisted reporting exercise with a human in the middle. The goal is to show where automation helps, where its authority must stop, and which decisions still require human judgment.

The book is meant to remain on the shelf as a working reference. Nobody remembers every protocol, control, framework, failure mode, or command. Experienced practitioners look things up. The useful skill is knowing what question to ask, where to verify the answer, and how to test whether the decision works in the actual environment.

Architecture is a way of thinking

One of my favorite parts of the conversation was our discussion about the gap between what textbooks or certification courses teach and what businesses need from engineers and architects.

Training often teaches what to do. Architecture requires knowing how to think about what should be done in a specific situation.

A business cannot harden every system to a theoretical maximum without considering availability, cost, customer impact, regulation, staffing, technical debt, and the risk introduced by the change itself. Security is an exercise in risk treatment. A strong compliance result can coexist with weak security if the organization treats evidence collection as the objective rather than a way to evaluate controls.

The architect has to translate business objectives into security requirements and constraints. That includes uncomfortable tradeoffs. Some risks are mitigated. Some are transferred or avoided. Others are accepted by the person with the authority and accountability to accept them. The architect's job is to make the choice explicit, explain the consequences, and define how the result will be verified.

This is also why the book uses free, community, and open-source tooling wherever practical. Readers should be able to reproduce the exercises in a homelab and examine how the controls work. A product can make implementation easier, but it cannot replace the reasoning that selected the control or the evidence that proves it works.

AI increases pressure on patching and supply chains

Our discussion then moved into AI-assisted vulnerability discovery and the growing strain on traditional patch cycles. My position is that organizations need to think beyond patch management and toward threat management.

A monthly maintenance window is not a complete vulnerability strategy. Threat modeling helps teams identify likely attack paths, understand where controls already reduce exposure, and prioritize remediation according to the system's real risk. Defense in depth matters because no single patching process will move at the speed of every new finding. Secure development practices, controlled CI/CD pipelines, segmentation, monitoring, and tested compensating controls all have a role.

AI also increases software supply-chain risk. It can help attackers search large codebases, scale reconnaissance, create convincing contributions, and find opportunities in dependencies and development workflows. It can also introduce insecure code when people accept generated output without understanding or testing it.

AI should remain a tool. In high-impact workflows, a human must remain in the decision path. Agents need narrow permissions, explicit boundaries, reliable telemetry, and limits on the systems and data they can affect. In my own environment, most AI-assisted access is constrained and read-only. Where greater privilege is required, it is bounded to a defined task and control path.

The answer to unreliable automation is not unlimited automation supervising more unlimited automation.

Zero trust still applies

Rich asked whether AI means zero trust has run its course and security needs a new paradigm. I do not think it has.

The fundamentals still apply. Define trust levels. Segment systems and data. Authenticate the actor and workload. Authorize the requested action. Limit privileges. Reevaluate context. Record what happened. Test the paths nobody expected to be used.

AI does not invalidate those principles. It gives organizations another fast and occasionally unpredictable actor that must operate inside them. If an agent can reach a repository, browser, SaaS platform, management API, secret store, and deployment system with broad standing authority, the problem is not that zero trust became obsolete. The architecture granted too much trust and failed to explore the "what if" paths.

The same reasoning applies to offensive security. An authorized engagement has a defined scope. AI-assisted testing does not erase that boundary. Rules of engagement, points of contact, technical containment, logging, and a clear stop condition become more important when the tooling can act faster than the operator can manually inspect each step.

Quantum readiness starts with the systems we already have

The quantum discussion was necessarily more speculative. Public claims about major hardware breakthroughs need independent validation, and nobody should build an enterprise migration plan around a headline. The need for cryptographic inventory and migration planning, however, is already real.

NIST released its first three finalized post-quantum cryptography standards in 2024 and advises organizations to begin transitioning. Architects do not need to predict the date of a cryptographically relevant quantum computer before starting the work that takes years: finding where cryptography is used, identifying long-lived sensitive data, locating hard-coded algorithms and certificate dependencies, evaluating vendor support, and designing crypto-agile replacement paths.

Legacy systems are where this becomes difficult. Every large organization seems to have a system that cannot be patched, replaced, or even restarted without a meeting. Some control an expensive machine. Others carry a business process written decades ago by someone nobody can locate. They may not support modern cryptography, much less post-quantum algorithms.

Those constraints do not disappear because a migration deadline arrives. Organizations need an inventory, a business owner, isolation, narrowly controlled access, compensating monitoring, a recovery path, and a funded replacement strategy. Quantum readiness is partly a cryptography program. It is also another reason to confront legacy-system risk before an external event forces the timing.

Concentration creates failure domains

Near the end of the interview, we discussed the attraction of all-in-one security platforms. Consolidation can reduce licensing, management overhead, and integration work. It can also turn one overloaded or attacked control into a shared failure domain.

I described an organization that routed internal segmentation, DMZ traffic, and external connectivity through the same active-active firewall pair. A low-and-slow denial-of-service attack stayed below the upstream provider's mitigation threshold but exhausted the shared platform. External connectivity failed, and internal network traffic failed with it. The eventual repair cost more than designing separation into the environment would have cost at the start.

This does not mean a firewall should perform only one function or that every layer needs a different vendor. It means architects must identify concentration risk. Ask what fails together, what remains reachable during an attack, how management access is preserved, and whether a control protecting one boundary can take down unrelated trust zones. Convenience and resilience are not the same thing.

Advice for people entering cybersecurity

We closed with advice for people trying to enter or grow within cybersecurity. Entry-level job descriptions often demand years of experience, and the field is sometimes presented as a quick solution to career frustration. That combination contributes to discouragement and burnout.

The better path is to build durable fundamentals. Learn networking. Learn Linux and Windows. Understand operating systems, identity, scripting, applications, logs, and how data moves. Practice in a lab. Break things you are authorized to break, restore them, and document what you learned. Learn how to use AI, but do not mistake prompt technique for technical understanding. Without the fundamentals, it becomes much harder to recognize a confident wrong answer.

Imposter syndrome does not vanish at a particular title. A dependable reference can help, but so can accepting that experienced people verify their assumptions. I maintain a recommended reading list covering security, technology, scripting, architecture, and organizational management because no single book, including mine, can cover the field permanently.

The fundamentals are not the beginner material we leave behind. They are what let us reason through new technology without being controlled by its marketing.

Thanks to Rich and the 2GuysTek community

I appreciated the opportunity to have an honest conversation with someone who understands infrastructure, security engineering, and homelabs from direct experience. Rich gave the book a careful reading and asked questions that moved naturally between technology, business, careers, and the systems organizations are likely to inherit rather than design from scratch.

You can watch the complete conversation, including the sections on the second edition, AI, zero trust, quantum readiness, critical infrastructure, and career development, on the 2GuysTek YouTube channel. Also consider subscribing to 2GuysTek to continue learning more about technology from a great channel. Also check out their other links and resources at 2GuysTek website.

The tools will change. The attack surface will change. The speed will change. The architect's responsibility remains: understand the system, ask what can fail or be abused, constrain trust, make the tradeoffs visible, and verify that the controls work outside the diagram.