Teaching cybersecurity in 2026: when output is cheap, discernment is the work

For several years now, I have been teaching cybersecurity to newcomers to the field. Each cohort takes half a year to train: zero to hero. This year brought the largest change to the curriculum yet. Not mainly in what we teach, but in how we teach it.

The 2026 AI challenge

Our academy embraced AI from the beginning, but we initially gave it a secondary role: supply pointers to information, not the information itself. AI was not powerful enough to provide a full answer. For the answers it gave, it was easy to judge when they were implausible or lacked contact with reality. This phenomenon was even given a name: hallucination.

This year, AI outputs are often plausible and logical—and when they are wrong, they can be extremely polished hallucinations. This means “not knowing” is no longer the problem. The world has shifted from scarcity of information to abundance of information. We had to adjust our academy to prepare students for this new reality accordingly.

We stopped treating raw information as the main thing to teach, and we stopped rewarding raw artifacts as proof of skill. Instead, we taught discernment and rewarded testable choices that earn their place by surviving contact with relevance, practicality, and pushback.

As with everything new, I have iterated over several smaller moves that pushed in the same direction and accumulated across the season. This made the new curriculum subject to its own laws: it had to survive contact with reality.

From tourist to detective

Some courses follow what I call the “tourist” model. They take the students to a place, take pictures, then move on to another place. In this model, exercises show you how it looks when it works, not how to help yourself when it does not. Complex commands are ready to copy and paste instead of being explored or explained. Questions have right answers, instead of less wrong ones.

The move from tourist to detective is that students get to explore safely on their own rather than always being guided. The tourist model builds confidence from borrowed success. The detective model builds skill from eliminating failure. Such skill is more transferable and more robust. 

Before learning a technique, students first learned how to query the system: debugger before Python fluency, manual exploration before Metasploit, log traces alongside actions and attacks. The most durable learning was: “when you're stuck, it does not mean you've failed—it means you've skipped a step in the cycle of predicting, testing, and adjusting”. 

We applied this lens to ourselves—lecturers and coaches—too. When a student asked for help, we first asked “how do you interpret what you see” instead of pointing out the error. Even technical issues became allies—we walked the students through the same process we'd use to fix something, sometimes even involving the whole class. This gave the most valuable lesson: the lecturer is not an oracle of knowledge; they are simply well trained in discernment, diagnostics, and thinking aloud.

Training the discernment muscle

Over the course of the season, we kept rediscovering that beginners do not need more knowledge upfront as much as they need reliable mechanisms to control uncertainty. So we kept training this muscle instead of memorizing facts.

Across early studies of news articles, producing risk briefs and disciplines like OSINT (finding and correlating publicly available information), the move was always the same: capture what is known, separate what is unknown, state the cheapest next test to discriminate. The mantra was: “if you don't understand the answer, you've not asked a question”.

It is both a human and an AI tendency to fill unknowns with guesses. The students learned to sharply separate conclusions that can be drawn from the available data from the ones that can't, and present them openly instead of waiting until everything is known. They now also demand the same answer format from AI.

Perhaps this is why cybersecurity was always pictured as hard to learn. The question-first mindset was too implicit and picked up only by seasoned engineers or talented newbies who somehow “got it”. By making this move explicit and putting it to the forefront, we've reduced the barrier to entering the industry. 

Attacks are built on failed assumptions

When it comes to offensive security—breaking stuff—the tourist mode of presenting attacks is a bag of tricks, sometimes with poetic names like Kerberoasting. It also leaves students with the simplistic conclusion that “tool X breaks system Y”.

The detective mode transformation of teaching attacks was “less breadth, more depth”. Across different attack types—cryptographic, network, cloud, Windows—the useful question became: what assumption did this system make that is no longer true?

A password attack became a lesson about password strength assumptions, not necessarily about Hydra as a tool. Upload RCE shifted from a PHP trick into the failed assumption that uploaded files are inert data, while the server may treat them as executable code. IDOR turned into a lesson about confusing authentication and authorization: knowing who the user is does not prove they may access a particular document.

Once students could name the failed assumption, the defensive move became less mysterious. Check passwords against known-bad dictionaries. Keep user input as data. Store uploads where they cannot execute. Check authorization on the object, not just the session.

Understanding these relationships allowed us to portray offensive security less like a collection of tricks with fancy names and more like a bridge into threat modeling: what assumptions does the system depend on, and how would we notice when they stop being true?

Making discernment testable

By the end, even the final test had adopted this shape. Instead of asking for complete flow diagrams, lists of controls, or “correct” answers, we scored small bits of discernment: a defensible conclusion with reasoning, evidence, and clearly stated limits. Full points were not awarded for long answers. They were awarded for answers that were clearly under control.

Here's an example: instead of asking “what attack is shown in this process tree?”, we asked “explain why this process tree is consistent with phishing, and what further evidence would you seek to confirm or reject this hypothesis?” 

The grading later confirmed the design. Two graders could work in parallel more easily because the unit of judgment was visible: conclusion, evidence, reasoning, limits. We no longer had to spend as much time deciding whether an answer was correct by accident or backed by actual work.

Plausible AI-assisted answers did not look fundamentally different from ordinary answers, but loss of control did. The weak answers became too broad, used queries the student could not really own, or submitted screenshots without explaining what they proved. The stronger answers explained their logic, and that explanation often became a self-check: does my result actually answer the question?

Did detective mode stick?

The strongest sign that the detective mode was working was that the students' language changed. Cybersecurity was no longer about how to hack or how to win a challenge. According to their feedback, it became more like this:

• There's no perfect defense, just better and worse decisions.
• The goal is not to know everything but to orient quickly.
• “I don't know this yet” is not a failure, it's a foundation for further work.

The best part is that this is not a cybersecurity or teaching quirk. It applies anywhere discernment matters more than raw output, especially when AI becomes a key part of a process and we do not want it to become a shortcut around thinking.

The detective mode can be summarized as:

Do not center your work only around output. Ask what can be rejected, what can be defended, and what would change your mind. In a world where plausible output is cheap, discernment is where the real work has moved.