A financial services team recently ran one of our breach-response exercises and performed almost flawlessly. They knew exactly which host to isolate, which account to disable, which step came next. And then they stopped, because no one in the room could authorize the action without a senior sign-off that wasn't available. They had the capability, but they couldn't execute it.

That gap, between what a team has built and what it can actually do when under pressure, is the most consistent thing we see at TryHackMe. We work with more than a thousand security teams, through skills development, our SOC simulator, and tabletop exercises, and the same pattern surfaces again and again. Similar controls, comparable tooling, trained staff, documented playbooks. However, underneath the surface, a wide variance in what any of it amounts to in a real incident.

We call it the execution gap: the distance between what an organisation has built and what its people, processes, technology, and measurement can actually execute under pressure. It's the distance between owning a playbook and being able to pull the trigger on it. We see it in five specific places.

Where we see the execution gap

Across the teams we assess, the execution gap lives in the same five dimensions of a SOC's maturity and each one fails in a recognizable way:

• People and culture: trained does not equal ready. Certifications completed; capability never validated under pressure.
• Processes and procedures: documented does not equal executable. A playbook on the shelf is not the same as one a team can run mid-crisis.
• Technology: deployed does not equal effective. Tools bought and switched on, then left to drown the team in alerts.
• Testing and validation: tested does not equal improved. The exercise happens; the change doesn't.
• Measurement and continuous improvement: tracked does not equal acted on. Dashboards that look good in a board pack but drive no behaviour.

The published data bears it out. In Sygnia's 2026 survey of 600 security leaders, 99% had a formal incident response plan, but still 73% of CISOs said they could not execute it under pressure if a major attack landed tomorrow. Ninety-nine percent was documented; yet seventy-three percent not executable. That is the gap, in two numbers, and we see the same shape across defence, financial services, retail, and telecommunications. These are the same gaps across different industries.

And then there's AI

Every conference, every booth, every board pack now comes with AI attached. But not only does AI not close the execution gap, it amplifies it. It makes strong SOC teams faster and weak ones more dangerous to themselves.

The uplift is real, as highlighted in a peer-reviewed Microsoft trial in late 2025 showing its phishing-triage agent producing six-and-a-half times more true positives per analyst minute. But that only holds when the underlying playbook is right. AI on a broken process doesn't fix that process; it runs the broken process at scale: faster wrong answers, delivered with more confidence. Gartner expects around 70% of large SOCs to be piloting agentic AI by 2028, and only 15% to reach sustainable production. The other 85% will have the dashboards. They won't have a loop that actually closes.

Asking whether to invest in AI isn't needed. Everyone will. Organizations should question whether the gap is small enough that the multiplier helps. Because if the gap is wide, AI widens it.

Sooner or later , the question arrives, usually from the people an organization least wants to improvise in front of such as the auditor, the insurer, the regulator, the board: can your team execute under pressure?

Closing the gap isn't something we can prescribe from the outside because every organization knows its own environment best. But the takeaway is the frame, not the framework:

Don't measure what you've built. Measure what you can do under pressure.

Want to close execution gaps within your cyber security team? Explore TryHackMe for Business.

When it comes to cybersecurity training, three things tend to separate the solutions with actual impact from what just looks good on paper: realism, hands-on practice, and a genuine feedback loop. Skip any of them and training still produces something that looks like capability but doesn’t test whether that capability can survive the pressure or ambiguity of a real incident.

Incident response makes that gap between checked boxes and performance under pressure more urgent than almost any other area of security work. There's no room to pause and study mid-breach, no partial credit for a mostly-right containment call, and no do-over if the wrong decision gets made while an attacker is still active.

Good incident response training operates across multiple layers, building the skill and testing whether it holds. These layers are related, but they're not interchangeable, yet most programs only ever focus, superficially, on the former.

What's the difference between building IR capability and validating IR capability ?

Capability building is individual and technical. Its goal is competence: can this analyst read a memory dump, interpret Windows event logs, follow an attacker's movement across a file system, work confidently across Windows, Linux, and macOS. It's structured, progressive, and knowledge-driven.This is the foundation everything else depends on.

Capability validation operates at a different level entirely. It isn't just about whether the team coordinates well, it's about whether all the scattered pieces an analyst has picked up separately, a SOC simulation here, a learning path there, months of individual on-the-job experience, actually come together coherently. When executed effectively, a cyber range forces that integration: bringing the team together has to draw on all of that learning at once.

That difference in focus is where the character of each layer becomes clear. Skill-building and skill-testing are sequential, not competing: one produces the skills, the other checks whether they survives contact with something that behaves like a real incident.

Think of it like training for a rescue team: individual members can be excellent swimmers, strong navigators, calm under pressure, each on their own. None of that guarantees they'll coordinate well during an actual rescue, with incomplete information, in the water, together. That coordination is its own skill, and it only gets tested when the team is actually in it.

Here's how the two compare, category by category:

• Primary goal
• Capability building: Build individual technical competence
• Capability testing: Prove coordinated team performance
• Pace
• Capability building: Self-paced, progressive
• Capability testing: Real-time, pressured
• Key question
• Capability building: Can this analyst perform the task correctly?
• Capability testing: Do the team's scattered skills and experience come together as one capability? Can they contain a live attacker before time runs out?
• Output
• Capability building: Certified, competent individuals
• Capability testing: A pressure-tested, coordinated team
• Who needs it
• Capability building: The analyst, for career progression
• Capability testing: The security leader, for operational assurance
• When it happens
• Capability building: Ongoing, throughout an analyst's development
• Capability testing: Quarterly, or after major team or environment change
• How it informs the other
• Capability building: Provides the raw capability a team draws on
• Capability testing: Surfaces the gaps individual training can't see

How hands-on practice fits into an IR training program

Hands-on practice runs through both layers, it just changes character as the training progresses.

At the skill-building stage, hands-on means realistic labs: messy, multi-host environments with incomplete logging and red herrings, not sanitized single-artefact exercises that hand an analyst a clean dataset. Judgment starts to form here, beyond vocabulary. As training moves toward team readiness, hands-on practice means live, unfolding scenarios where the "environment" is the whole incident, not a single task, and where a wrong decision has a consequence inside the simulation, beyond a scorecard.

Feedback connect the two. A pass/fail result at the end of a module or a simulation is a data point, but it’s not a loop. Real improvement comes from reviewing the decision, as well as the outcome: two analysts can reach the same right answer through very different reasoning, and only one of those paths holds up in a different scenario. Debriefs immediately after a simulation, while the reasoning is still fresh, do more for a team's development than any score attached to the exercise itself.

TryHackMe's own Identification & Scoping room makes this concept explicit rather than incidental, treating identification and scoping as a continuous loop, with event notification, documentation, evidence collection, artefact identification, and pivot point discovery, feeding back into itself as new evidence surfaces.

Where IR training sits in a security team's development

The need for real skill-testing tends to surface as a security function matures. Early-stage teams are focused on getting foundational detection and response coverage in place. As the function grows, and as the incidents it faces get more complex, the gap between "our analysts are trained" and "our team is ready" becomes harder to ignore.

That evolution maps onto individual career progression too. Detection and triage skills at L1, deeper investigation at L2, and increasingly senior IR roles as forensic and coordination skills grow. Each stage builds on the last, and giving analysts visible progression through this path is one of the more practical ways security leaders develop and retain senior talent.

What makes strong incident response capability distinctive is that modules only get a team to the threshold. The rest is built through repeated exposure to realistic, pressured conditions, which is exactly what a checklist of completed courses can't demonstrate.

Building the skill and testing whether it holds: individual vs team training

Individual skill development follows a logical progression: foundational SOC skills first, then deeper investigation capability, then the specialized forensic and response skills that senior IR work demands, file system analysis, memory forensics, artefact interpretation across operating systems. Cross-platform breadth matters because real environments aren't uniform, and an analyst who's only comfortable on one platform is a limited one.

Team readiness is a different challenge entirely. The coordination between analysts, the escalation calls, the handoffs, the communication while working from incomplete information, none of that gets tested by individual training, no matter how advanced the content. It only gets tested in conditions that behave like a real incident.

That gap between individual readiness and team readiness is one of the least visible problems in security training, and one of the most consequential. It doesn't show up in a training record or a completion rate. It shows up mid-incident, when discovering the gap is no longer useful information. A team that's individually strong but has never been pressure-tested together is working on assumption.

Where individual skill-building actually happens

Within the TryHackMe platform, the "capability building" layer is a specific set of hands-on modules, each building a different piece of incident response skills that an analyst eventually has to bring together in a live incident.

• Defensive Security — A foundation across SOC fundamentals, digital forensics fundamentals, incident response fundamentals, and log fundamentals in one place, the starting point before specializing
• Core SOC Solutions — Practical fluency with the tooling a SOC runs on: EDR, SIEM (via Splunk and the Elastic Stack), and SOAR
• Managing Incidents — The security engineer's side of an incident: logging and monitoring, acting as a first responder, and cyber crisis management
• Incident Response — The tactical mindset of an effective responder, walking through preparation, identification and scoping, threat intel and containment, eradication and remediation, and lessons learned
• Incident Response Lifecycle — One real attack chain worked start to finish across, aligned with NIST phases, with findings from each phase carrying into the next, the same way an analyst would work it on the job
• Cyber Defence Frameworks — Applied use of the Pyramid of Pain, Cyber Kill Chain, Unified Kill Chain, and MITRE to map telemetry, build framework-driven triage notes, and harden detection and response
• Incident Response and Forensics — Artifact analysis with Volatility, Redline, and Autopsy to understand the scope of an incident and contain it
• Digital Forensics and Incident Response — Deeper forensic work across Windows and Linux artifacts, using KAPE, Zimmerman's tools, Autopsy, Volatility, and TheHive to collect, organize, and act on evidence

A few of these up close, to show what "hands-on" actually means in practice:

• Identification & Scoping (Incident Response module) walks a real scenario at a fictional company, SwiftSpend Financial, introducing the Asset Inventory and the Spreadsheet of Doom as working tools, not just concepts to memorize.
• Response and Recovery (Incident Response Lifecycle module) continues a single incident at another fictional company, Nexus Financial, where analysts use MITRE ATT&CK to inform containment decisions and Splunk to analyze what the attacker did after the initial compromise.
• Intro to IR and IM and Becoming a First Responder (Managing Incidents module) cover the distinction between incident response and incident management, and what to do in the first minutes after discovering an incident, before the formal IR team takes over.
• Windows Incident Surface puts analysts on a live, compromised Windows VM to hunt for hijacked environment variables, suspicious services and scheduled tasks, and other persistence mechanisms, exactly the kind of triage work a real investigation starts with.

Worked through in sequence, these cover the full individual arc: foundational awareness, core tooling, the operational response process, the full lifecycle against one continuous incident, the analytical frameworks that structure how a team reads adversary behavior, and increasingly deep forensic capability.

How TryHackMe supports incident response training

For most security teams, building this capability starts with the individual layer, the modules above, along with the broader blue team learning roadmap: SOC L1 and L2 paths build the detection and investigation skills everything else depends on, and the Advanced Endpoint Investigations path extends that into digital forensics across Windows, Linux, and macOS for analysts ready to go deeper.

Individual training gets a team to the threshold, but it leaves those skills scattered: a SOC simulation here, a learning path there, individual experience picked up on the job. What it can't do is pull all of that together into one coherent capability. That's the gap Live Breach is built to close: a realistic, end-to-end, time-limited IR scenario in a relevant environment, where a team has to bring everything they've learned separately into a single live incident, and contain the attacker while the attack is still actively executing. It's a true test of whether all their scattered skills and experience actually add up to one real capability under pressure.

Want to turn theoretical cyber security training into proven capability? Explore TryHackMe for Business

FAQ

What does good incident response training actually look like? Good incident response training combines individual skill-building, modules and hands-on labs that build technical competence, with regular, live team simulations that test whether that competence converts into coordinated performance under real time pressure. Programs that stop at the individual layer look complete but leave team readiness untested.

What's the difference between individual training and team-based incident response training? Individual training builds technical skill: forensic analysis, log interpretation, platform-specific investigation, but it stays scattered across separate modules and experiences. Team-based training, usually a live, time-limited scenario, forces all of that to come together at once, testing whether a team can actually contain a live attacker while the attack is still executing, not just whether the pieces exist individually.

How often should security teams run live incident simulations? Most mature security teams run team-based simulations quarterly at minimum, with additional sessions after significant team changes, new tooling, or a meaningful shift in the threats relevant to their environment.

Why do feedback loops matter more than pass/fail scores? A pass/fail result shows whether the outcome was correct, not why. Reviewing the decision-making behind a result, ideally in a debrief immediately after a simulation, is what actually helps a team improve, since two people can reach the same right answer through reasoning that won't hold up in a different scenario.

Ask most security leaders whether their team is ready for AI risk and you’ll get some variation of a yes. Ask them to specify what exactly they’re ready for, and the answer will get murky. The industry has been nodding along to "AI ready" for some time, without agreement on a definition.

AI-readiness is more than having deployed a tool. It means being clear on the problem you expect AI to solve, where the limitations of its remit are, and understanding specifically what risk you are taking on by using AI in a given part of your business. Crucially, it’s also knowing whether your team actually has the skill to identify and manage that risk. Too few organizations have not done the work needed to clearly answer on all these points. In fact, they need to revisit these questions continuously as the answers evolve.

AI adoption has outpaced the problem definition

We spoke with security leaders across healthcare, finance, automotive, manufacturing and insurance while building our new AI security path, and one theme came back again and again: AI systems are already running in production, handling sensitive data, in every one of those industries, and much of that happened without anyone stopping to define what problem the AI was actually solving or what new exposure it was creating in return.

Teams are being asked to protect systems they do not understand end to end, so what usually gets deployed in response is a patchwork of small, disconnected controls rather than a coherent framework built around an actual understanding of the risk. That is the same pattern that shows up whenever a tool gets adopted ahead of a clear problem statement.

Supply chain risk came up unprompted in nearly every conversation TryHackMe had, and it is a clean example of the same challenge: organizations adopting models and dependencies without first asking what they would need to verify or monitor once those components were inside their environment.

Training built on the wrong assumption doesn’t protect

Part of why this keeps happening is that most available training reinforces the assumption that AI risk is a known, static thing you can learn once and check off. Watching a lecture on prompt injection can make the concept click instantly, and then fall apart the moment someone sits in front of a real system with actual guardrails and tries to extract the system prompt themselves.

Teams that can pass a knowledge check often cannot reason through a genuinely novel problem, which suggests the theory never really transferred into judgment. Much of the training on the market only simulates the AI itself, which makes it deterministic: the same input always produces the same output.

Real AI systems do not behave that way. Two identical prompts can return two different responses, and that unpredictability is the actual attack surface defenders are up against. If your training does not reproduce that unpredictability, it cannot teach anyone to define the real problem they are facing, only a simplified stand-in for it.

Readiness means defining the scope of AI’s remit

Genuine AI readiness looks a lot like the discipline any good problem definition requires, applied specifically to security. It means being able to say, for a given system, exactly what you are trying to protect against, who owns that risk, and where the human needs to stay in the loop regardless of how convincing the AI's output looks.

That accountability does not sit exclusively with the security team. Every engineer writing code with an LLM, every team pulling a model from a repository, every workflow with AI stitched into it is expanding the exposure, and a manager who pushes AI adoption for the sake of productivity is also, whether they realize it or not, taking on responsibility for what happens if that usage was never scoped properly. A security incident tied to ungoverned AI use rarely stays contained to the security function. It carries consequences for brand trust, regulatory standing, and revenue, and it traces back to the point where nobody paused to ask what specifically was being adopted, and why.

Building capability across teams

Getting your organization ready for safe AI implementation does not start with more tooling. In a security context, it means hands-on practice against real, non-deterministic AI systems rather than simulations, coverage broad enough to span the full threat landscape rather than one narrow slice of it, and honest engagement with supply chain risks that most training skips past entirely. Things like backdoored tokenizers, poisoned checkpoints, and typosquat dependencies hiding in a model repository. It also has to reach past the security team itself, since developers, DevOps, and engineers are already on the front line of AI usage whether or not their job title reflects that.

AI is an opportunity to reframe the role of the security team

AI is an opportunity for the security team to break out of its reputation as the as the team that says no, and claim a strategic role in guiding the business through implementation and adoption.

Security has spent a long time earning a reputation as a blocker, preventing or stalling decisions made elsewhere in the business, often without its involvement. AI adoption is happening at a pace and with a level of executive pressure that makes that old posture untenable. Saying no to a board level mandate does not work, and it should not be the goal. What works, and what actually builds influence, is being the voice in the room asking the question necessary to prevent legal liability, lost reputation and reputational damage that can’t be easily undone. Far from obstruction, this is strategic leadership that can align a group of stakeholders feeling the rushed to achieve vaguely defined goals.

To make that shift, teams need to push to be looped in while decisions are still being shaped, proving they can move at the speed of the business. Success will be more than a successful implementation of new technology, it’ll be a redefinition of the organization’s relationship to security as a discipline and as an organizational function.

That redefinition includes taking on a greater role as stewards of understanding across the org. With the vulnerabilities AI usage creates, security needs to become a shared language, shared goal and shared responsibility in every department. Superficial yearly awareness training isn’t enough to manage threats in a post-AI world. The cyber team can lead this change, building strategic allies along the way.

Want to turn theoretical cyber security training into proven capability? Explore TryHackMe for Business

A threat intelligence analyst studies attackers rather than just their attacks, turning raw data about threat actors, malware, and campaigns into intelligence that helps an organisation defend itself before an incident happens rather than after. It sits within blue team work, but it is a distinct discipline from SOC analysis or incident response, closer to research and pattern recognition than real-time alert triage. Most people reach it after a year or two in a SOC or security analyst role, though a direct path is possible for anyone who builds the right foundation early.

This guide walks through what the role actually involves day to day, the skills and certifications that matter, and the concrete first steps to take if this is the direction you want your career to go.

What does a threat intelligence analyst do?

A threat intelligence analyst collects information about threat actors, campaigns, and malware from internal telemetry, commercial feeds, and open sources, then turns that raw data into intelligence a security team can actually act on. Day to day work includes tracking specific threat groups and their tactics, enriching indicators of compromise so a SOC can triage alerts faster, mapping adversary behaviour against frameworks like MITRE ATT&CK, and writing intelligence reports that translate technical findings into decisions a security leader or executive can use.

The distinction that matters most is between reacting and anticipating. A SOC analyst responds to what is happening right now on the network. A threat intelligence analyst spends more time answering who is likely to target the organisation, how they typically operate, and what that means for where defences should be strengthened next.

What skills do you need to become a threat intelligence analyst?

Strong analytical thinking matters more here than in almost any other blue team role, because the job is fundamentally about connecting scattered, ambiguous data points into a coherent picture of adversary behaviour. Alongside that, a working knowledge of the MITRE ATT&CK framework is close to non-negotiable, since it is the shared language most teams use to describe and compare attacker tactics, techniques, and procedures.

Open source intelligence gathering is a core practical skill, covering how to responsibly collect and validate information from public sources including forums, technical blogs, and social media without compromising an investigation. Familiarity with malware analysis fundamentals helps too, not necessarily at a reverse engineer's depth, but enough to understand what a sample reveals about the actor behind it. Intelligence report writing is the skill that is most often underestimated. A brilliant analysis that nobody outside the security team can understand or act on has limited value.

Do you need SOC analyst experience first?

Not strictly, but it is the most common and most practical route in. Working as a SOC or security analyst first builds the foundational understanding of how alerts, logs, and incidents actually look in a live environment, which makes intelligence work far more grounded once you get there. It also gives you real internal telemetry to contextualise against, which is one of the four broad categories of intelligence sources alongside commercial feeds, open source data, and information sharing communities.

Career changers without a security background typically start with a foundational certification and an entry-level analyst role, then move into intelligence work once they have a year or two of that operational context behind them. It is a slower path than jumping straight into a niche specialism, but it produces analysts who understand what actually happens to the intelligence they produce once it reaches a SOC.

Which certifications matter for threat intelligence?

No single certification is required to break into the field, and hiring managers generally value one foundational credential paired with one threat-intelligence-specific one over a long list of unrelated badges. According to ZipRecruiter's July 2026 data, the average annual pay for a Cyber Threat Intelligence Analyst in the United States sits at $109,848, with the middle range of salaries falling between roughly $87,500 and $130,000 depending on experience and location.

How do you build a portfolio without real client data?

The lack of access to real intelligence feeds and internal telemetry is the biggest practical barrier for anyone trying to break in from outside a security role, but it is not an unsolvable one. Writing analysis on publicly documented threat actors and campaigns using open source reporting builds exactly the same skills a job would ask for, and it produces something tangible to show a hiring manager.

Public malware repositories and threat feeds provide real samples and indicators to practise against without needing employer access to anything sensitive. Structuring that practice around a defined methodology, rather than ad hoc research, is what makes it read as professional work rather than a hobby project.

Start building the foundation for threat intelligence work

Threat intelligence rewards people who can turn scattered, ambiguous information into a clear picture of what an adversary is likely to do next. That skill is built through structured practice against real frameworks and real attacker behaviour, not by reading about the role from the outside.

Frequently asked questions

How long does it take to become a threat intelligence analyst? Expect roughly 18 to 24 months if you are starting from an IT or general security background, and longer if you are starting from outside the field entirely. The timeline mostly depends on how quickly you build hands-on SOC or analyst experience first.

Do you need a degree to work in threat intelligence? No specific degree is required, though the analytical and research skills the role demands are often developed through higher education or equivalent self-directed study. Employers generally care more about demonstrated analytical ability and a portfolio of work than the credential itself.

What is the difference between GCTI and CTIA? GCTI from GIAC is the more advanced, specialist-focused credential with no formal prerequisites but an assumption of existing security knowledge. CTIA from EC-Council targets entry to mid-level analysts and requires either official training or two or more years of experience.

Is threat hunting the same as threat intelligence? They overlap but are not identical. Threat hunting is the proactive search for signs of compromise already present in an environment, while threat intelligence is the broader discipline of understanding who attackers are and how they operate, which often informs what a threat hunter goes looking for.

What career progression comes after threat intelligence analyst? Common next steps include senior threat analyst, threat intelligence team lead, or threat research manager roles. Some analysts specialise further into areas like nation-state threats or financial crime intelligence, while others move into strategic security advisory or leadership positions.

SQL injection is a web application vulnerability that lets an attacker interfere with the queries an application sends to its database, by sneaking their own SQL code into a field the application never expected to contain code at all. Done successfully, it can expose an entire database, bypass a login screen without a password, or hand an attacker control of the server underneath. It has been a known vulnerability class since the late 1990s, it still ranks among OWASP's top web application risks today, and it remains one of the first things any penetration tester or bug bounty hunter learns to test for.

This guide walks through what SQL injection actually is, how it works under the hood, the main types you will encounter, and how to practise finding and exploiting it safely, without ever touching a system you do not have permission to test.

What is SQL injection?

Most web applications talk to a database behind the scenes. A login form checks a username and password against a database table. A product page pulls its description from a database record. A search box queries the database for anything matching what you typed. All of that happens through SQL, the language almost every relational database understands.

SQL injection happens when an application takes something a user typed and drops it directly into a SQL query without properly separating the data from the command structure. If an attacker can shape their input carefully enough, the database stops treating it as data and starts treating part of it as an instruction. A username field becomes a place to alter what a login query actually checks. A search box becomes a place to pull data the application was never designed to return.

How does SQL injection actually work?

Picture a simple query behind a blog's article page, structured something like this:

<code>SELECT * FROM articles WHERE id = 1 AND private = 0;</code>

That query fetches the article with an ID of 1, but only if it is marked public. If the application builds this query by directly inserting whatever value comes from the URL, an attacker can change the id parameter to something like <code>1; --</code>. The semicolon tells the database the query has ended, and the double dash comments out everything that follows, including the <code>AND private = 0</code> check. The result: an article that was supposed to be private gets returned anyway, because the condition that would have blocked it never actually ran.

That is the essence of every SQL injection attack. The application trusted user input to behave like data. The attacker made it behave like code instead.

What are the different types of SQL injection?

Not every SQL injection vulnerability behaves the same way, and the type you are dealing with changes how you detect and exploit it.

Classic and union-based injection are the easiest starting point for beginners because the feedback is immediate. Blind injection takes longer to master because you are inferring the answer one true or false question at a time, but the underlying logic is exactly the same.

Where can you practise SQL injection safely and legally?

Every technique above needs to be practised somewhere, and that somewhere cannot be a live website you do not own or have explicit permission to test. Doing this against a real, unauthorised target is illegal, regardless of intent, and it is also unnecessary. Realistic, deliberately vulnerable environments exist specifically so you can build this skill without any legal or ethical grey area.

TryHackMe's SQL Injection room walks through exactly the scenario described earlier in this guide, a vulnerable blog application where you progress from a basic in-band injection through to union-based data extraction, with a mock browser and live SQL query view so you can see precisely how your input reshapes the query in real time. Once the fundamentals feel solid, the Advanced SQL Injection room covers blind and time-based techniques against a target that gives you no direct feedback at all, forcing you to build the inference skills that real-world blind injection demands.

How do you detect and confirm an SQL injection vulnerability?

Detection starts with breaking things on purpose. Add a single quote to any input field that touches a database query, a URL parameter, a login form, a search box, and watch what happens. A clean application handles it gracefully. A vulnerable one throws a database error, behaves unexpectedly, or changes its output in a way that reveals the query underneath.

From there, the process is methodical rather than clever. Confirm the injection point, work out how many columns the original query returns, then build up from a simple proof of concept toward whatever the vulnerability actually allows, whether that is reading data, bypassing authentication, or in the most severe cases, writing to the database or the underlying file system. OWASP classifies injection as one of the most heavily tested vulnerability categories in modern web applications, and SQL injection specifically still accounts for more than 14,000 recorded CVEs, which tells you how often this exact mistake still makes it into production code.

How do you prevent SQL injection?

Every reliable defence against SQL injection comes down to the same principle: never let user input become part of the query structure itself. Parameterised queries, sometimes called prepared statements, are the standard fix. They separate the SQL command from the data being passed into it at the database driver level, so no matter what a user types, it is always treated as a value and never as executable code.

Object-relational mapping libraries provide this protection by default in most modern frameworks, which is part of why classic SQL injection has become less common in new applications, even as it remains widespread in older or poorly maintained code. Input validation and least-privilege database accounts add further layers, but they are supplements to parameterised queries, not substitutes for them.

Frequently asked questions

Is SQL injection still a real threat in 2026? Yes. It remains part of OWASP's injection category, and legacy applications along with poorly reviewed new code continue to introduce it. It has fallen in ranking as awareness has grown, but it has not disappeared.

Do you need to know SQL to learn SQL injection? Basic SQL helps but is not a strict requirement to start. Understanding simple SELECT statements and how a WHERE clause filters results is usually enough to begin, and the rest builds naturally through hands-on practice.

What is the difference between error-based and blind SQL injection? Error-based injection reveals information directly through database error messages. Blind injection reveals nothing directly, so you infer the answer to yes or no questions through changes in the application's behaviour or response time instead.

Can SQL injection be automated with tools? Yes, tools exist to automate detection and exploitation, but relying on them without understanding the underlying mechanics limits how effectively you can adapt when a target behaves differently than expected. Learning it manually first makes any tool far more useful later.

Does SQL injection only affect websites? No. Any system that builds SQL queries from user-controlled input is potentially vulnerable, including desktop applications, APIs, and internal tools, not just public-facing websites.

Start practising SQL injection the safe way

SQL injection is not a niche skill. It is one of the most consistently useful things a beginner in offensive security can learn, precisely because the underlying idea, that mixing data and commands is dangerous, shows up again and again across other vulnerability classes once you understand it here first.

Start the SQL Injection room on TryHackMe

Every week, companies pay strangers on the internet to break into their websites. Not illegally. Not maliciously. On purpose, with permission, and often for genuinely good money. That is bug bounty hunting, and if you have ever wondered how people get paid to hack, this is where it actually starts.

Here is the part most beginner guides skip. Bug bounty hunting is not a shortcut into cyber security, and it is not a get rich quick scheme either. It is a skill you build the same way you would build any other technical skill: methodically, with the right foundations, on the right targets, in the right order. Skip the foundations and you will spend months submitting reports that get marked as duplicates or not applicable. Build them properly and your first valid finding becomes a matter of consistency rather than luck.

This guide walks through what bug bounty hunting actually is, how the ecosystem works, what you need to know before you touch a target, and how to get your first hands-on practice safely.

What is bug bounty hunting?

A bug bounty program is an open invitation from a company for security researchers to test their systems and get paid for anything they find. The company defines a scope, which is the exact list of what you are allowed to test, sets reward tiers based on severity, and reviews every report that comes in. Find something real and valid inside that scope, and you get paid. Find something outside the scope, and at best it gets ignored. At worst, it gets you banned from the platform.

This is what separates bug bounty hunting from the kind of hacking that gets people arrested. You are operating with explicit, written permission, against a defined target, under a defined set of rules. That permission is what makes it legal, and it is also the single most important thing a beginner needs to understand before doing anything else.

How do bug bounty platforms actually work?

Most bug bounty hunting happens through a handful of platforms that connect companies with researchers. HackerOne and Bugcrowd are the two largest, hosting programs for household names alongside thousands of smaller companies. Intigriti has strong momentum in Europe, YesWeHack runs a similar model with its own community, and Synack operates a vetted, invite-only tier for more experienced researchers.

TryHackMe is not a bug bounty platform itself, it does not run programs or pay bounties, but it is where the skills tested on every platform above are actually built, which is why it sits at the top of this list rather than off to the side.

Every one of these platforms is free to join. Sign up, browse public programs, and read a handful of scope documents before you write a single line of a report. That single habit, reading the scope properly, is what most beginners skip and most experienced hunters insist on.

What should you look for in a scope document?

A scope document tells you what is in scope, what is explicitly excluded, which vulnerability types the program does not pay for, and what legal protections you have while testing. Programs with wide scopes, active response times, and a track record of paying out are the ones worth starting on. A program where every public report says the team is slow or dismissive is not worth your time, no matter how well known the company is.

Avoid the temptation to hunt on the biggest names first. Google, Meta, and Apple attract thousands of experienced researchers who have been testing those same targets for years. As a beginner, you are far more likely to find a genuine, valid bug on a smaller company or a Vulnerability Disclosure Programme, where the attack surface has had far less scrutiny.

What do you need to know before you start?

Bug bounty hunting rewards a specific kind of technical foundation, and web applications are where almost every beginner starts. You do not need a computer science degree or years of programming experience, but you do need to genuinely understand how the web works underneath the interface.

That means understanding how HTTP requests and responses are structured, how cookies and sessions keep a user logged in, how authentication and authorization actually differ, and how data moves between a browser and a server. It also means having a working knowledge of the vulnerability classes that show up again and again in real programs: cross-site scripting, SQL injection, insecure direct object references, cross-site request forgery, and server-side request forgery. The OWASP Top 10 exists because these categories account for the overwhelming majority of real-world findings, and learning them properly is worth more than jumping straight to advanced techniques.

Burp Suite is the one tool almost every hunter relies on daily. It sits between your browser and the target, letting you intercept, inspect, and manipulate requests before they are sent. Learning Burp Suite properly, rather than relying on someone else's automated macros, is one of the highest-value skills you can build early.

Where can you practise before touching a live program?

This is the step that separates people who quietly quit after a few weeks from people who land their first valid report. Testing on a live company's assets before you understand what you are doing is how beginners get banned, waste their own time, or worse, cause real harm to a system they do not fully understand. Practising first, on safe and legal environments, is not optional.

TryHackMe's Jr Penetration Tester path builds exactly the web application foundation this guide has been describing, walking through HTTP fundamentals, the OWASP Top 10, and Burp Suite in a structured, hands-on order rather than leaving you to piece it together from scattered blog posts. The Web Fundamentals module covers how web applications are built and how that structure creates the vulnerabilities you will spend your career finding. Rooms like NahamStore simulate a realistic, deliberately vulnerable e-commerce application, giving you a safe space to practise real bug classes without any legal or ethical grey area.

Once the fundamentals feel comfortable, look for a Vulnerability Disclosure Programme rather than a paid bounty program for your first real-world attempt. VDPs do not pay cash, but they accept beginners more readily, tend to have simpler scopes, and let you build a track record and reputation score without the pressure of chasing a payout.

How long does it actually take to find your first bug?

Longer than most people expect, and that is normal. Most beginners take several weeks of consistent, focused effort before their first valid report, and that is with a solid foundation already in place. Depth on a single target consistently beats switching between dozens of programs looking for something easy. Pick one target, spend real time understanding how it works, and work through every input field, form, and endpoint methodically rather than relying purely on automated scanners.

How do you write a report that actually gets paid?

A vulnerability is only as valuable as the report describing it. Triage teams see hundreds of submissions, and a clear, well-structured report gets reviewed faster and taken more seriously than a vague one. A strong report includes a short, impact-focused summary, numbered steps to reproduce the issue exactly, a proof of concept, and a plain-language explanation of why the vulnerability matters. Screenshots, short recordings, or copy-pastable commands all reduce the back and forth a triage team needs before they can validate what you found.

Treat every interaction with a program's triage team professionally, even when a report gets marked as informational or a duplicate. Reputation compounds on these platforms. Researchers who submit thoughtful, well-documented reports and respond quickly to follow-up questions get invited to private programs faster than those chasing volume over quality.

Frequently asked questions

Do you need to know how to code to start bug bounty hunting? No. A basic understanding of HTML, JavaScript, and how HTTP requests work is more useful than programming ability. Most beginner-friendly bug classes, like XSS or IDOR, are found through careful manual testing rather than writing code.

Is bug bounty hunting legal? Yes, as long as you stay within a program's defined scope and follow its rules. Testing anything outside that scope, or testing a system without a program or written permission at all, is not legal and can carry serious consequences.

How much can beginners realistically earn from bug bounty hunting? Earnings vary enormously and most beginners earn very little in their first few months. Rewards for valid bugs commonly range from around fifty dollars for low-severity issues to several thousand for critical ones, but consistency and skill take time to build.

Do you need a cyber security degree or certification to start? No. Bug bounty hunting rewards demonstrated skill over credentials. Certifications like OSCP can help later for career purposes, but they are not required to find and report valid vulnerabilities.

What is the difference between a bug bounty program and a Vulnerability Disclosure Programme? A bug bounty program pays cash rewards for valid findings. A VDP accepts vulnerability reports and provides recognition or reputation points but does not pay. VDPs are generally more accessible for beginners building a track record.

Start where the fundamentals are strongest

Bug bounty hunting rewards people who understand web applications deeply, not people who memorise a list of payloads. Build that understanding properly first, practise on safe and legal ground, and the transition to real programs becomes a natural next step rather than a leap of faith.

Machine learning models are not neutral tools. They are systems with attack surfaces, and those surfaces are being actively exploited. Adversarial machine learning is the discipline that studies how attackers manipulate, evade, and compromise ML systems, and how defenders protect them.

For cyber defenders in 2026, this is no longer a research topic. It is operational reality. The ML-based detection tools in your SOC, the AI models processing threat intelligence, the LLM-powered automation in your security workflow: all of them are targets. Understanding how adversarial attacks against ML systems work is what makes you able to defend against them.

What Is Adversarial Machine Learning?

Adversarial machine learning (AML) is the study of attacks against machine learning systems and the defences built to counter them. NIST documents four main adversarial ML attack categories: evasion, poisoning, privacy, and abuse attacks. Each targets a different phase of the ML lifecycle and requires different defensive controls.

The term "adversarial" refers to the adversary-centric framing: rather than asking "how does this model perform on clean data?", adversarial ML asks "how does this model perform when an intelligent attacker is deliberately trying to make it fail?"

For defenders, the practical implication is this: if your organisation depends on ML-based tools for detection, classification, or decision-making, those tools have attack surfaces that traditional security controls were not designed to address. MITRE ATLAS (Adversarial Threat Landscape for Artificial Intelligence Systems) is the definitive framework for understanding and defending against these threats. As of February 2026, ATLAS v5.4.0 contains 16 tactics, 84 techniques, and 42 real-world case studies - growing rapidly as the attack surface expands.

What Are the Four Main Adversarial ML Attack Categories?

Evasion Attacks

Evasion attacks occur at inference time. The attacker crafts inputs designed to cause the model to produce incorrect outputs - without changing the underlying content in a way that a human would detect.

The canonical example is adversarial examples against image classifiers: imperceptible pixel-level perturbations that cause a correctly-classified image to be misclassified with high confidence. For cyber defenders, the more directly relevant application is malware evasion: attackers modify malware samples to evade ML-based detection while preserving full malicious functionality. A sample that bypasses your ML detector does not need to exploit a code vulnerability in the detector. It just needs to fall outside the decision boundary the model learned during training.

For LLM-based systems, evasion includes guardrail bypass through encoding tricks, Unicode manipulation, and carefully constructed prompts that cause a model to produce outputs its safety controls were designed to prevent.

MITRE ATLAS technique: AML.T0015 (Evade ML Model)

Defender implication: ML-based detectors need adversarial robustness testing as part of their validation. A detector that performs well on clean samples but fails on adversarially perturbed ones provides a false sense of security.

Poisoning Attacks

Poisoning attacks occur at training time. Adversaries inject inaccurate or malicious data into training datasets - sometimes controlling only a few dozen training samples - to influence the model's learned behaviour. The attack can be designed to degrade overall model performance (availability attack) or to embed a backdoor: a specific trigger that causes the model to misclassify a particular input in a way the attacker controls (integrity attack).

For defenders operating threat intelligence systems or any model that learns from data sources partially outside your control, poisoning is a realistic threat. An attacker who can influence what goes into your training data can influence what your model learns to detect - and what it learns to ignore.

Data poisoning and backdoor attacks are among the fastest-growing documented attack categories in ATLAS. The Spring 2025 ATLAS release added RAG Poisoning and False RAG Entry Injection as specific techniques, reflecting the rapid adoption of retrieval-augmented generation in enterprise AI deployments.

MITRE ATLAS technique: AML.T0020 (Poison Training Data)

Defender implication: Data provenance and integrity controls matter as much as model accuracy. Know where your training data comes from, who can modify it, and whether any data sources are accessible to external parties.

Privacy Attacks

Privacy attacks extract information that should not be accessible from a trained model. The two main categories are:

Model inversion: An attacker queries the model with carefully crafted inputs to reconstruct information about the training data. In healthcare or financial contexts, this can mean recovering sensitive personal information from a model trained on private records.

Membership inference: An attacker determines whether a specific data point was included in the model's training set. This can violate data protection requirements and confirm sensitive information about individuals.

Model extraction: An attacker queries the model extensively to build a local copy (a shadow model) that approximates the original's behaviour. The shadow model can then be used for offline adversarial attack development without triggering rate limiting or monitoring on the original.

MITRE ATLAS technique: AML.T0024 (Infer Training Data Membership), AML.T0025 (Model Inversion Attack)

Defender implication: Rate limiting, query monitoring, and differential privacy techniques all apply. A model that can be queried without restriction or monitoring is significantly more vulnerable to all three privacy attack types.

Abuse Attacks

Abuse attacks use ML systems as intended - but for purposes their operators did not authorise. Prompt injection is the most operationally significant abuse attack for defenders in 2026: manipulating an LLM's behaviour through crafted input that overrides system instructions or causes the model to take unintended actions.

The LiteLLM incident in March 2026 illustrated how supply chain compromise affecting ML infrastructure can produce a large blast radius across all dependent deployments. Supply chain compromise targeting ML dependencies, training frameworks, and inference servers is a documented and growing attack vector.

MITRE ATLAS technique: AML.T0051 (LLM Prompt Injection), AML.T0010 (ML Supply Chain Compromise)

Defender implication: Input validation, output filtering, privilege separation, and supply chain security controls all apply to ML systems. Treat LLM applications as you would any other privileged software component.

The Adversarial ML Attack Reference Table

How Do You Learn Adversarial Machine Learning as a Cyber Defender?

The challenge with most adversarial ML learning resources is that they are written for ML researchers, not security practitioners. They assume familiarity with neural network architecture, gradient descent, and loss functions before getting to the attack techniques that matter operationally.

TryHackMe's AI Security path is built for security practitioners. It covers adversarial ML concepts through the defender's lens: not how to train a model from scratch, but how to understand where models break, how attackers exploit those breaks, and what controls apply. The 25 hands-on labs put you inside live AI systems working with the techniques that matter operationally.

Specific rooms directly relevant to adversarial ML defenders:

AI Threat Modelling covers MITRE ATLAS-based assessment: mapping your AI systems' attack surface against the ATLAS tactics and techniques matrix, prioritising the techniques most relevant to your deployment, and designing controls against them.

LLM Security covers prompt injection and jailbreaking from both the attacker and defender perspective. You run the attacks against live LLM systems and then apply the defensive controls that reduce exposure.

AI Supply Chain Security covers dependency integrity, supply chain attack vectors, and how to assess and secure the ML libraries and infrastructure your deployments depend on.

AI Forensics covers what investigation looks like when an AI system has been attacked: what artefacts to collect, how to determine whether a model was poisoned, and how to reconstruct what happened.

AI1, TryHackMe's AI Security certification, validates this skill set across 13 hands-on scenarios covering both offensive and defensive AI security. It is the first practical AI security credential available on any platform. Premium subscribers receive a 15% discount.

FAQ

How is AI being used in cyber security attacks and defences? On the offensive side: AI-generated phishing that is indistinguishable from legitimate correspondence, adaptive malware that modifies its own code to evade signature-based detection, automated vulnerability discovery at a scale and speed that human researchers cannot match, and deepfake-based fraud that bypasses traditional social engineering awareness. On the defensive side: ML-based anomaly detection that identifies threats without requiring known signatures, AI-assisted alert triage that reduces the volume analysts need to review manually, automated threat intelligence enrichment, and LLM-powered investigation assistance that accelerates root cause analysis. Both sides are using the same underlying technology. The defenders who understand the offensive applications build better detection logic.

How do you defend against AI-powered cyber attacks? Defending against AI-powered attacks requires controls at multiple layers. For AI-generated social engineering: procedural verification through a separate channel for any high-value request, regardless of how legitimate the initiating message appears. For adaptive malware evasion: behaviour-based detection that identifies what a process is doing rather than matching against known signatures, combined with heuristic analysis that catches novel variants. For adversarial ML attacks against your own AI systems: adversarial robustness testing as part of your model validation pipeline, data provenance controls for training data, and monitoring for anomalous query patterns that suggest model extraction or evasion attempts. For AI agents with tool access: least privilege on tool permissions, input validation, and output filtering before any agent action takes external effect.

What is MITRE ATLAS and how does it relate to MITRE ATT&CK? MITRE ATLAS is the AI-specific counterpart to MITRE ATT&CK. ATT&CK maps adversary tactics and techniques against traditional IT infrastructure. ATLAS maps them against AI and ML systems. As of February 2026, ATLAS v5.4.0 contains 16 tactics, 84 techniques, 56 sub-techniques, and 42 real-world case studies. If you already use ATT&CK for threat modelling and detection engineering, ATLAS applies the same structured approach to your AI attack surface. Approximately 70% of ATLAS mitigations map to existing security controls, making integration with current SOC workflows practical rather than requiring entirely new defensive infrastructure.

Five years ago, Eddie Tumalle was working part-time as a phone technician / Sales. Today, he's a SOC analyst with three cyber security certifications earned in just three months. His secret weapon? Consistent, hands-on practice and a TryHackMe license he made the absolute most of.

This is Eddie's story: how he pivoted from retail to IT to cyber security, and how TryHackMe helped him close the skills gap that theory alone couldn't.

The Spark: A Mentor and a Plan

Eddie's journey started with a conversation. While working as a phone technician, he met a colleague who managed a Security Operations Center at Boeing. That mentor gave him advice that shaped everything: build a strong IT foundation first, and pick up HR-friendly certifications along the way.

Eddie listened. He earned his A+ and IT support certifications, then made his first big move  leaving retail behind for the IT department at T-Mobile.

Finding the Gaps

IT gave Eddie real, transferable skills. Root cause analysis and documentation would later serve him well in the SOC. But when he set his sights on cyber security, he knew the learning curve would be steeper so he did something smart. He reached out to a former SOC team member and asked a simple question: what does the day-to-day actually look like, and where will I struggle?

The answer was honest. Eddie had gaps in:

• Reading raw logs and making sense of them under pressure
• Understanding network traffic at a deep level
• Navigating Splunk, the SIEM his company relied on
• The security side of Azure Active Directory

He didn't need more theory. He needed reps.

Enter TryHackMe

When T-Mobile sponsored TryHackMe licenses for its team, Eddie jumped in hard. He used the platform so heavily that he topped the company leaderboard for three months straight.

What made it click for him was the format. TryHackMe's structured learning paths gave him guidance instead of guesswork, and the hands-on labs meant he wasn't just reading about concepts he was doing them. The Security Analyst path in particular stood out, with the opening Security 101 section praised for building foundations the right way: Linux fundamentals, setting up a virtual machine, and the core concepts everything else stacks on.

Along the way, Eddie built exactly the skills he'd been missing:

• Raw log analysis: no longer intimidating, now second nature
• In-depth Splunk experience: directly relevant to his target SOC role
• The MITRE ATT&CK framework: and how real investigations map to it
• The investigator's mindset: the SOC Simulator tied all the theory together in realistic scenarios

Every one of those skills, in Eddie's words, transferred directly to the actual SOC environment.

Passing SAL1: Two Days After Getting the License

When Eddie heard about licenses to sit TryHackMe's Security Analyst Level 1 (SAL1) exam, he spoke to his managers, secured one, and took the exam two days later.

He passed.

His verdict? The SAL1 exam is a genuine representation of what starting in a SOC actually feels like. It forced him to navigate Splunk properly and proved he had the practical foundation the job demands.

It also changed his certification strategy entirely. Eddie found that TryHackMe's material covered more  and went deeper than the traditional entry-level security certification he'd originally planned to take. So he skipped it, made SAL1 his foundational credential instead, and used it as a springboard to a more advanced analyst certification. He passed both exams in the same week.

Three certifications. Three months. Nearly all of it fueled by intense, hands-on study.

Turning Learning Into Proof

Eddie's advice to anyone chasing a SOC role is blunt: employers want proof, not promises. A project portfolio is no longer optional in a competitive market.

So he built one  drawing directly from what he learned on TryHackMe:

• Built his own firewall with pfSense, then took it further by adding IDS/IPS detection with Suricata, a tool referenced in TryHackMe's learning material
• Installed and configured Splunk on a Linux server, documenting the whole process  directly relevant, since his company runs on Splunk
• Documented everything on GitHub  steps, screenshots, diagrams  creating a portfolio he could point to in interviews

The documentation habit paid a hidden dividend: writing everything up forced him to review the material multiple times, which organized his thinking and gave him real confidence walking into interviews.

The Payoff

Eddie made it. He's now on the SOC team the goal he set five years ago as a phone technician.

He's clear about what got him there: without TryHackMe's structure, his journey would have been slower and far less streamlined. The learning paths gave him direction, the SOC Simulator gave him confidence, and the hands-on labs made sure nothing he learned slipped away.

And he's not done. Once he's settled into the SOC, Eddie plans to return to TryHackMe for the red team learning path and its certification because he believes reaching that higher technical level makes every other area of cybersecurity easier to master.

Eddie's Advice for Aspiring SOC Analysts

1. Build your IT foundation first. The skills transfer more than you think.
2. Talk to people in the role. Find your gaps before an interviewer does.
3. Get hands-on. Theory alone won't survive contact with a real investigation. Platforms like TryHackMe exist so you can practice in real-world scenarios.
4. Turn learning into projects. Firewalls, detection systems, SIEM setups, build them, document them, show them off.
5. Ask about a company-sponsored license. Eddie's employer sponsored his TryHackMe access, complete with a leaderboard and monthly rewards. Yours might too.

Three Words

When we asked Eddie to describe TryHackMe, he didn't hesitate:

Practical. User-friendly. Relevant.

We couldn't have said it better ourselves.

There are definite limitations when organizations approach cybersecurity certifications individually. There’s a common sequence of events: an analyst decides they want a certification, their manager approves the budget, and the certification gets added to that analyst’s CV. It’s useful, but it’s not a program. With nearly two-thirds of managers (59%) citing critical or significant skills needs this year, a change in approach is crucial.

A certification program is something different:

• It gives every role in a cyber team a clear credentialing path.
• It tells managers where each analyst actually stands against a verified standard.
• It creates a shared baseline the whole team can be measured against.
• And it produces the kind of objective, third-party evidence that leadership and auditors
  can act on.

Building that program requires the right certifications at the right levels, and a platform that makes them manageable at scale.

Why most security certifications fall short for teams

The majority of widely recognized security certifications were designed for individual career development, and are detached from the needs of hiring organizations. This creates a specific problem for managers trying to build an actionable understanding of team readiness.

Moreover, these certifications test what practitioners know: they rely on multiple-choice exams, theory-heavy content, and narrow domain coverage, but misses the validation of practical skills that demonstrates job-readiness. Passing proves that an analyst has studied a topic. It doesn't tell you whether they can execute under pressure in a real environment.

For managers of cyber teams, that gap matters at every stage of the employment lifecycle:

• New hires arrive with certifications on their CV that tell you what they've studied, not what they can do in your environment
• Existing analysts may hold certs that are years old, acquired before the threat landscape looked anything like it does today
• Promotions and role changes get made on tenure and gut feel rather than verified evidence of capability at the next level
• Leadership conversations about team readiness rely on anecdote rather than data

Hands-on, job-aligned certifications close that gap. They put candidates inside realistic environments and ask them to perform, so managers get a verified signal they can actually use.

What a team certification program looks like

A well-structured certification program maps credentials to roles and seniority levels, creates clear progression paths, and gives managers a central view of where the team stands at any point.

TryHackMe's certification portfolio is built around this model. Every exam is hands-on, browser-based, and designed to reflect the actual demands of the role. There are no multiple-choice questions. Candidates work in live environments against real scenarios and are assessed on what they can do, not what they can recall.

The TryHackMe certification ladder spans six certifications, each designed for a specific role and career stage. Together they create clear progression pathways from onboarding a non-technical hire to validating a senior SOC analyst ready for L2 responsibilities.

SEC0 | Pre Security

Who it's for: Cyber-adjacent roles, early learners, career switchers, non-technical business staff, interns

What it validates: Core cyber concepts and terminology: computer, OS, and network fundamentals, how the web works, attacks and defenses

Why it matters: No IT or tech background required. SEC0 gives non-security staff the vocabulary to engage meaningfully with the team, and acts as the first step on the TryHackMe learning journey. [Learn more about the SEC0 certification]

SEC1 | Cyber Security 101

Who it's for: Career starters, students, interns, junior cyber team members (0–2 years experience)

What it validates: Foundational offensive, defensive, and investigative skills across 7 practical sections: OS and network fundamentals, Red Team, Blue Team, and scenario-based tasks. No MCQs.

Why it matters: Browser-based and integrated with the TryHackMe learning path, so candidates can prepare and assess in the same environment. Targets the actual job skills needed for a first role. [Learn more about the SEC1 certification]

SAL1 | Security Analyst Level 1

Who it's for: L1 SOC analysts, new hires, onboarding cohorts

What it validates: Real-world SOC work in a simulated environment, built specifically for the L1 analyst role and developed in collaboration with Salesforce and Accenture

Why it matters: The go-to onboarding benchmark. Spots capability gaps before new joiners touch live systems. Tells managers what they're actually working with. [Learn more about the SEC2 certification]

SAL2 | Security Analyst Level 2

Who it's for: Mid-senior analysts ready to validate seniority, SOC managers making promotion and succession decisions

What it validates: Technical depth, operational judgment, and stakeholder communication across 12 scenario-based investigations delivered in a 72-hour window — including SIEM analysis (Splunk/Elastic), compromised machine access, PCAP and malware triage, detection engineering with Sigma, incident summary writing, customer-facing updates, SLA management, and threat classification

Why it matters: The only certification at this level that tests communication and escalation alongside technical skills, because that is what separates senior analysts from junior ones. Provides an auditable, third-party benchmark for promotion decisions, budget cases, and regulated environments. [Learn more about the SAL2 certification]

PT1 | Junior Penetration Tester

Who it's for: Entry-level offensive security practitioners and red team members

What it validates: Offensive skills across web, network, and Active Directory, including a full-stack simulated penetration test

Why it matters: Validates offensive capability before an analyst takes on offensive responsibilities. Built by industry experts and designed to mirror the reality of an engagement. [Learn more about the PT1 certification]

AI1 | AI Security Level 1

Who it's for: Security teams and AI-adjacent roles working with AI-enabled systems

What it validates: End-to-end AI attack and defense skills on live systems — live chatbots, RAG knowledge bases, and model artifact environments — covering prompt injection, supply chain security, data poisoning, and remediation

Why it matters: Aligned with OWASP LLM Top 10 and CompTIA SecAI+. As AI becomes embedded in more environments, AI1 gives teams an objective measure of whether they can actually defend against the threats that come with it. [Learn more about the AI1 certification]

Building the program: SAL1 and SAL2 as the backbone of a SOC certification journey

For defensive cyber teams, Security Analyst Level 1 and Security Analyst Level 2 are the natural anchors of a team certification program. They are not just two standalone assessments, but present a connected growth path. SAL1 establishes a verified baseline for every analyst on the team. SAL2 defines what senior readiness actually looks like. Together, they give managers something most certification programs never offer: objective evidence of capability at both ends of the L1-to-L2 progression.

Security Analyst Level 1: Establishing a Verified SOC Baseline

Security Analyst Level 1 is built specifically for L1 SOC analysts. It was developed in direct collaboration with Salesforce and Accenture, grounded in what the role actually demands rather than what a syllabus committee agreed on.

Candidates work inside a simulated SOC environment, triaging alerts, investigating incidents, and writing case reports across scenarios that reflect the tooling and workflows analysts encounter day to day. There are no theory questions, the assessment is entirely task-based.

For managers, SAL1 solves a specific and persistent problem: onboarding without a verified baseline. When every new joiner is expected to achieve SAL1 before handling live systems, the team has a consistent, objective foundation. When existing analysts hold it, the manager has confidence that a shared standard exists across the team.

SAL1 also gives L1 analysts a concrete and credible target. They can see exactly what proficiency looks like, and work toward it with purpose rather than waiting for someone to tell them they're ready.

Security Analyst Level 2: Validating the Step Up

SAL2 picks up where SAL1 leaves off. It’s built for analysts who have developed their foundational skills and are ready to demonstrate they can operate at a senior level: independently, under pressure, across the full scope of what L2 SOC work actually involves.

That scope is broader than most certifications acknowledge. Across 12 scenario-based investigations in a 72-hour window, SAL2 candidates handle real incidents using Splunk or Elastic, access compromised machines, conduct PCAP and malware analysis, and work through detection engineering with Sigma. They are also assessed on stakeholder communication like incident summary writing, customer-facing updates, SLA management, and threat classification, because that is what separates L2 analysts from L1 analysts in practice.

For managers, SAL2 turns a subjective promotion decision into an evidence-based one. For the analysts themselves, it is a meaningful milestone that reflects genuine achievement, not accumulated tenure. And for the business, it is an auditable signal of operational readiness that holds up in regulated environments and leadership conversations alike.

The SAL1-to-SAL2 path is the clearest growth journey in defensive security certification. It tells a consistent story: this is what entry-level readiness looks like, and this is what senior readiness looks like, with objective evidence at both points.

Where certifications fit in the wider capability picture

Certifications validate what analysts can do at a point in time. They answer a specific management question: is this person ready for this level of responsibility? But they work best when they sit inside a broader capability management approach.

At onboarding, certifications replace assumption with evidence. A new joiner with Security Analyst Level 1 has a verified baseline. One without it gets a structured path to achieve it before handling live systems.

At progression points, certifications like Security Analyst Level 2 make promotion and succession decisions objective. Rather than relying on tenure or the opinion of a senior colleague, managers have verified evidence of performance at the next level of complexity, including the operational judgment and stakeholder communication skills that actually separate L1 from L2.

During role transitions, certifications flag readiness before responsibilities change. An analyst moving from a defensive to a more offensive role can work toward Junior Penetration Tester to validate the skills the new position requires, rather than discovering gaps in production.

For cyber-adjacent teams, certifications like Pre Security and AI Security Level 1 give non-technical roles the foundation to understand what the security team is dealing with, and give IT, legal, and compliance functions the grounding to participate meaningfully in security programs and incident response. AI Security Level 1 makes existing security skills current for all skill levels, by adding the crucial context of a new attack surface.

For ongoing readiness, certifications catch capability drift before it becomes operational risk. Skills that aren't practiced against current material decay quietly. A structured recertification cadence keeps the team's verified baseline current.

The Manager Dashboard in TryHackMe gives teams a central view of certification status across the whole cyber team: completions, retakes, upcoming expiry, and where gaps exist by role. The program stays visible and manageable rather than drifting on autopilot.

What leadership needs from a certification program

The business case for a structured certification program is straightforward. Leadership needs to know the cyber team is capable of handling the threats the organization faces. Regulatory frameworks increasingly require demonstrable evidence of security workforce readiness. Auditors ask for it, boards are starting to ask for it.

Job titles and tenure are proxies, while certifications from a hands-on platform that assesses real performance in realistic environments are evidence.

Organizations need to treat certifications as a capability management tool, not an individual career benefit. To map credentials to roles, track status centrally and build progression paths that show analysts where they're going and give managers the data to support investment decisions with something more than instinct.

[Explore TryHackMe's certification program for cyber teams.]

Want to turn theoretical cyber security training into proven capability? Explore TryHackMe for Business

Frequently Asked Questions

What is the TryHackMe Security Analyst Level 1 (SAL1) certification? Security Analyst Level 1 is a hands-on SOC analyst certification from TryHackMe, built specifically for L1 analysts and developed in collaboration with Salesforce and Accenture. Candidates work inside a simulated SOC environment: triaging alerts, investigating incidents, and writing case reports, with no multiple-choice questions. It is designed to validate what analysts can actually do in a real environment, not what they can recall from a textbook.

What is the TryHackMe Junior Penetration Tester (PT1) certification? Junior Penetration Tester is an entry-level offensive security certification from TryHackMe. It validates practical skills across web application testing, network penetration, and Active Directory attacks, and includes a full-stack simulated penetration test. It is designed for red team practitioners and analysts who work across offensive and defensive responsibilities.

What is the difference between TryHackMe Security Analyst Level 1 and Security Analyst Level 2? Security Analyst Level 1 is designed for L1 SOC analysts and establishes a verified baseline of core defensive skills in a simulated SOC environment. Security Analyst Level 2 is designed for mid-senior analysts and goes further, assessing not just technical depth across endpoints, networks, cloud logs, and SIEM platforms, but also operational judgment, incident communication, and stakeholder reporting across 12 scenario-based investigations in a 72-hour assessment window.

Are TryHackMe certifications recognized by employers? TryHackMe certifications are hands-on and job-aligned, developed with input from practitioners and industry partners including Salesforce and Accenture. They are designed to validate real operational capability rather than theoretical knowledge, which makes them meaningful to hiring managers and security leaders who need evidence of what candidates can actually do.

How long does it take to complete TryHackMe's Security Analyst Level 1 certification? Security Analyst Level 1 is a flexible, on-demand assessment. TryHackMe provides an integrated learning path to help candidates prepare, and the exam itself is non-proctored with one free retake included. Preparation time varies depending on existing experience, but the SOC L1 learning path is designed to be worked through consistently alongside operational responsibilities.

Can managers track certification progress across their cyber team? Yes. TryHackMe's Manager Dashboard gives team leaders a central view of certification status across the whole team — including completions, retakes, and upcoming expiry dates. It sits alongside broader team performance and skill gap data, so certification progress is visible in the context of overall capability management rather than as a separate tracking exercise.

What TryHackMe certifications are suitable for non-technical or cyber-adjacent roles? TryHackMe's Pre Security certification (SEC0) is designed for learners without a technical background, covering core cyber concepts and terminology across seven modules. It is well suited to IT, legal, compliance, and business roles that need to understand the security landscape and participate meaningfully in security programs and incident response. AI Security Level 1 (AI1) is also relevant for AI-adjacent roles across the organization, covering end-to-end AI attack and defense skills on real AI systems.

All SOC managers have a rough sense of where their team stands, regardless of the tools they’re working with. They know who the strong analysts are, have a feel for which threat categories the team handles well and which ones make them nervous, and they’ve seen the training completion rates in their company’s LMS.

What they rarely have is any of that in a form they can act on, report upward, or build a strategy from. Why would they, if their platform doesn’t offer them the intelligence?

Most cyber security training platforms on the market were built to develop individual skills, but fail to give a manager the insights or collaborative environments needed to develop team capability as a strategic, always-on function.

The result is a common and costly gap: training activity that’s disconnected from business risk, invisible to leadership, and fails to evidence actual readiness.

Individual cyber training is the foundation, not the finish line

Individual skill development is, of course, an irreplaceable part of capability development for modern SOC teams. Thanks to AI, threat actors are more efficient and sophisticated than ever before. Hands-on, job-aligned learning paths, certifications mapped to role and seniority, as well as regular practice against current threat material are all non-negotiable. A team cannot be ready if its analysts aren't capable.

But individual capability is just that: a part. A team of individually strong analysts who have never practiced responding together, and never stress-tested their escalation paths or made real decisions under shared pressure, is not a ready team. It's a collection of capable individuals who haven't become an operational unit.

It’s the interplay between individual development and the cultivation of a team that works in alignment that most cyber security training platforms miss. They optimize for the individual and stop there, preventing managers and leadership from getting the layer of evidence that really gauges how the SOC will perform during a real incident.

What does a platform for individual and team SOC training look like?

Individual development and team readiness aren't competing priorities, they're more like complementary layers. Each one makes the other more valuable. Here's how they work together:

Individual development: the foundation

Individual skill development is where readiness starts. TryHackMe's learning paths and certifications are hands-on, job-aligned and mapped to role and seniority. Analysts are building skills relevant to what they'll actually face, rather than generic coursework.

Individual benchmarking: pressure-testing what's been built

CTF Events surface how individual skills [or team dynamics] hold up under real competitive pressure. Run them to identify your strongest performers, or as a full-team event to benchmark the whole group. Either way, the results feed directly into your picture of where individual capability actually stands vis-a-vis the team.

Team and individual performance visibility: connecting individuals to collective coverage

The Management Dashboard shows how individual progress maps to team-wide coverage. At a glance, managers can see:

• Skill gaps by role and threat area
• Engagement trends and long-term capability improvement
• Where the team is strong and where it's exposed
• Whether investment is moving the needle, with export-ready data to show leadership

Hands-on practice: where individual skills indicate team capability

This is the layer most platforms don't have. Three tools, each testing something different:

SOC Simulator — analysts work through the same live alert scenario independently, then debrief together on where decisions diverged. Surfaces coordination gaps and MTTR variance without waiting for a real incident to expose them.

Threat Hunting Simulator— hypothesis-driven investigations in realistic environments, from foundational hunts to APT-level scenarios. Analysts train on real attacker behavior, building the instinct to look for threats before they trigger an alert. Gives team leads meaningful data on how analysts investigate under pressure, and relevant for development decisions at every seniority level.

Organizational validation: demonstrated readiness

Tabletop Exercises — AI-generated from your context and documentation. Tests whether escalation paths hold under pressure, whether ownership is clear, and whether the team communicates effectively when it matters. Built in minutes, for regular implementation. Every session ends with specific actions and owners.

Live Breach Exercises — where assumed readiness becomes something you can evidence. TryHackMe delivers a simulation environment aligned to your context. The scenario evolves with ambiguity and shifting facts, covering each stage from an alert: detection, triage, and escalation, before moving into identification and scoping by higher-tier analysts and IR teams to verify and characterize the incident, then containment and isolation, eradication, recovery, and lessons learned. The output is a defensible record of organizational readiness that stands up to boards, auditors, and regulators.

How do management insights bridge individual and team SOC training?

For individual or team training to have strategic impact, there needs to be visibility. The TryHackMe Management Dashboard is the spine that connects every layer.

It surfaces individual and team-wide progress in a single view: skill gaps by role and category, engagement trends, long-term capability improvement over time. Learning paths can be aligned frameworks or job descriptions, so assignments connect to what the organization is actually measured against. Deadline tracking, seat usage, and active user data mean the program runs operationally. Export-ready reporting means leadership can actually engage with the team’s progress in context.

How does training activity become a cyber capability strategy?

The execution gap, the distance between what your team has been trained on and what they can execute under pressure, doesn't just close by adding more individual training. It closes when individual development is treated as the foundation of a broader capability strategy built to get teams to work in lock-step, whatever their mix of skills and seniority. This requires a platform that’s been built to manage, measure, and evidence from the individual analyst through to the entire SOC, with insights actually relevant to the board.

Want to turn theoretical cyber security training into proven capability? Explore TryHackMe for Business

MAX is our most powerful plan to date. It brings together the content that working practitioners have been asking for most: advanced learning paths that map to mid-career security roles, including AWS and Azure cloud security labs, a persistent AttackBox, recent threats content, and more. Built for practitioners who need to stay ahead, and for anyone who wants access to everything TryHackMe has to offer.

TryHackMe has been used by over 8 million people to learn and develop Cyber Security skills. A significant number of those people are working practitioners: SOC analysts, security engineers, penetration testers, incident responders. They came to TryHackMe to learn, and they stayed because it works.

That's why today (29 June 2026) we are launching MAX: a new plan built specifically for that audience.

What is MAX and how does it compare to Premium?

MAX sits above Premium, which continues to cover the broad range of learning paths and hands-on content that practitioners at every stage use. MAX adds the most advanced specialist paths, cloud labs, and current threat content on top.

Some of the paths currently in Premium are moving to MAX for new subscribers from 29 June 2026. If you subscribed to Premium on or before 29 June 2026, you keep access to those paths until July 2027. See the table below for the full picture.

⚠️ Web Application Red Teaming, Advanced Endpoint Investigations, Red Teaming and SOC Level 2 are moving exclusively to MAX for anyone signing up after 29 June. If you are an existing Premium subscriber, see below for how this affects your access.

⚠️ Attacking and Defending AWS & Defending Azure were previously only available on Business plans. MAX is the first time individuals can access them.

What's new in MAX

Advanced paths

The four paths at the top of a lot of practitioners' lists are now in MAX: Red Teaming, SOC Level 2, Web Application Red Teaming, and Advanced Endpoint Investigation. These are the paths that map directly to mid-career security roles: the work you are actually doing. Not the work you are preparing to do.

Cloud security paths

Until now, AWS and Azure labs on TryHackMe have only been available to organisations on Business plans. MAX changes that. AWS 101 (Attacking and Defending AWS) and Azure 101 (Azure Security) are now open to individual subscribers. The AWS 101 path will also be significantly updated, so if you have been through it before it is worth starting again.

Recent Threats

CVEs do not wait for course catalogues to catch up. Recent Threats is a continuously updated module with hands-on labs for the latest vulnerabilities. All new recent threats released from today now require MAX, with new labs added as threats emerge.

Persistent AttackBox

The Persistent AttackBox is exactly what it sounds like: a machine that stays alive between sessions. No more losing your work when a session ends. Files persist, installed tools persist, and spin-up is faster. If you spend serious time in the AttackBox, this is the feature you have been waiting for.

One thing to be clear about: if you downgrade from MAX, your AttackBox storage is permanently deleted and cannot be recovered. If you come back to MAX later, you start fresh.

⚠️ Important: Downgrading from MAX permanently deletes your AttackBox storage. This cannot be recovered. If you resubscribe to MAX later, you will start with a clean machine.

Certification discount

MAX annual plan subscribers get 40% off one TryHackMe certification per year. This applies to annual subscribers only, not monthly.

Pricing and how to upgrade

MAX is available on monthly and annual billing. If you are on an annual plan, you also get 40% off one TryHackMe certification per year. Visit the pricing page to get started.

🌍 On a legacy currency plan?

If you are currently billed in AUD, PLN, MXN, SAR, EGP, or another legacy currency, you will see a notification to contact our support team to upgrade to MAX.

What does this mean for you?

The launch of MAX involves some changes to how paths are distributed across plans, particularly for existing Premium subscribers. We have tried to make this as clear as possible. Below we cover the following scenarios, please skip to the situation that applies to you.

• Existing Premium subscribers (on or before 29 June 2026)
• New Premium subscribers after 29 June 2026
• Free TryHackMe users

The grace period applies to Premium subscribers who subscribed on or before 29 June 2026.

Note: if you cancel your Premium subscription at any point, your grace period access ends immediately and permanently, even if you resubscribe.

Existing Premium subscribers (subscribed on or before 29 June 2026)

If you are an existing Premium subscriber, you are not losing anything straight away. The four paths that are moving to MAX (SOC L2, Web Application Red Teaming, Red Teaming, and Advanced Endpoint Investigation) remain available on your Premium plan until July 30, 2027, provided your subscription stays active and uninterrupted.

⚠️ Important: If you cancel your Premium subscription, you will permanently lose access to the four paths included under the grace period. This applies even if you resubscribe to Premium later. The grace period does not reinstate once broken.

This grace period applies only if your Premium subscription was active on or before 29 June 2026.

Example, Case 1: You subscribed to Premium Annual in January 2026. You renew in January 2027. You keep the four paths until July 2027. After that, they move to MAX only.

Example, Case 2: You subscribed in January 2026, cancel or let your subscription lapse in January 2027, and resubscribe in February 2027. The grace period does not apply to the renewed subscription. The four paths will not be included in your Premium from February 2027.

⚠️ During cancellation, we will show a notice confirming you will lose access to these paths on Premium if you cancel.

New Premium users signing up after 29 June 2026

If you are creating your TryHackMe Premium account after 29 June 2026, the new plan definitions apply to you from day one.

Free TryHackMe Users

If you are on a free TryHackMe account, the four paths moving to MAX: Red Teaming, SOC Level 2, Web Application Red Teaming, and Advanced Endpoint Investigation - will no longer be accessible from 29 June.

If you want to keep going with any of those paths, MAX is the plan to be on.

FAQ

Q: Can I stay on Premium?

Yes. Premium is not going anywhere. However some paths (outlined in the table above) will be moving to MAX. Please check the section "What does this mean for you?" to find out more about when this will affect you. MAX adds the advanced practitioner content on top of Premium for those who need it.

Q: What happens to my AttackBox files if I downgrade from MAX?

Your AttackBox storage will be permanently deleted when you downgrade. This cannot be recovered. If you return to MAX later, you will start with a clean machine.

Q: I'm billed in AUD / PLN / MXN / SAR / EGP. How do I upgrade to MAX?

You will see a notification in your account prompting you to contact support. Our team will handle the upgrade for you. Please be aware that once upgraded, you will not be able to return to your previous legacy currency pricing.

Q: Will more content be added to MAX in the future?

Yes. New paths are planned throughout 2026 and 2027. See the roadmap table above.

Q: Does the 40% certification discount apply to monthly subscribers?

No. The certification discount is available to MAX annual plan subscribers only, and redeemable once per year.

Q: What happens to my grace period path access if I cancel my Premium subscription?

If you cancel, you permanently lose access to the four paths included under the grace period, even if you resubscribe to Premium afterwards. The grace period does not reinstate.

Q: When do the plan changes take effect?

For new sign-ups, the new plan definitions apply from 29 June. Existing Premium subscribers who subscribed on or before 29 June 2026 keep access to the four paths until 30 July 2027, provided their subscription stays active and uninterrupted.

Ready to level up?

Most cyber security certifications test what you have memorised. TryHackMe certifications test what you can actually do.

Every exam in the TryHackMe certification programme puts you inside a live environment with real tooling. No multiple choice. No theory questions. You investigate real alerts, run real attacks, and submit graded professional reports. The credential you earn is proof of practical ability, not exam technique.

Here is every TryHackMe certification, who it is for, and how to get there.

The TryHackMe Certification Ladder

Six certifications. A clear progression from complete beginner to advanced practitioner. Every one of them practical.

SEC0: Pre-Security Certificate

Who it is for: Complete beginners. Anyone who has never studied cyber security, networking, or operating systems before. People who want a formal first credential that confirms their foundational knowledge is solid before specialising.

What it proves: That you understand how computers, networks, and the internet actually work. Not security concepts yet. The layer below them: TCP/IP, how websites are served, how operating systems manage files and processes. The knowledge that makes every subsequent security concept meaningful rather than abstract.

The exam: Practical, scenario-based tasks. You apply knowledge to analyse situations rather than recall information from memory.

Preparation path: Pre Security path

Bundle: SEC0 and SEC1 together at 20% off. If you are starting from zero, the bundle is the most cost-effective route through both foundational credentials in one purchase.

Explore SEC0

SEC1: Security 101 Certificate

Who it is for: People who have completed SEC0 or already have IT foundations. Anyone who wants a formal entry-level credential before committing to a blue or red team direction. IT support, helpdesk, or networking professionals making the security pivot.

What it proves: Beginner-level cyber security knowledge across both offensive and defensive domains. This is the first credential that signals to an employer you understand the field, not just the infrastructure it runs on.

The exam: Structured practical assessment. You find answers through hands-on tasks rather than multiple choice.

Preparation path: Cyber Security 101 path

Bundle: SEC0 + SEC1 available at 20% off each. Premium subscribers receive a further 15% discount.

Explore SEC1

SAL1: Security Analyst Level 1

Who it is for: Anyone targeting a SOC analyst, blue team analyst, or security operations role at Tier 1 level. The most important credential for anyone whose career destination is defensive security.

What it proves: That you can investigate a real alert. Not in theory. The exam puts you inside a live SOC simulator with a real alert queue, real tooling, and graded incident reports. You triage alerts, investigate incidents, correlate log data across sources, and document your findings in professional format.

Backed by Accenture and Salesforce. When these organisations endorse a credential, it means their hiring teams recognise it. That is the practical signal that matters.

The exam: Live SOC simulator. Real alerts. Real tooling. Graded incident reports as part of the assessment.

Preparation path: SOC Level 1 path

Discount: Premium subscribers receive 15% off.

Explore SAL1

SAL2: Security Analyst Level 2

Who it is for: SOC analysts with Tier 1 experience who are ready to move into deeper investigation, threat hunting, and DFIR responsibilities. The credential for practitioners who want to lead investigations independently rather than triage from a playbook.

What it proves: Tier 2 investigation capability. Advanced multi-stage scenarios covering threat hunting, memory forensics, network traffic analysis, and the independent analytical depth that senior SOC roles require.

Pablo Menendez Cores, SOC Analyst at NCC Group, described SAL2 as "a strong and practical certification... it reflects quite well what we actually do in an MSSP environment." That is a practitioner at one of the most respected managed security services providers in the world validating what the exam tests.

The exam: Advanced multi-stage SOC investigation scenarios. Harder, longer, and more ambiguous than SAL1 by design.

Preparation path: SOC Level 2 path

Discount: Premium subscribers receive 15% off.

Explore SAL2

PT1: Junior Penetration Tester

Who it is for: Anyone targeting a junior penetration tester, red team analyst, or offensive security role. The right first practical certification before OSCP.

What it proves: That you can run a structured offensive security engagement and communicate findings professionally. A 48-hour practical exam across web application, network, and Active Directory targets. You attack live systems, document your findings, and submit a graded professional report. No shortcuts. No theory questions.

The exam: 48-hour practical engagement. Graded professional report. Live targets across web, network, and Active Directory.

Preparation path: Jr Penetration Tester path, rebuilt for 2026 with 89 rooms across 17 modules, a full nine-room Active Directory module, and three capstone challenges that mirror the exam format.

Discount: Premium subscribers receive 15% off.

Explore PT1

AI1: AI Security Certificate

Who it is for: Security practitioners who want to be ahead of where the industry is heading. Penetration testers who need to assess AI systems. Defenders who need to detect and respond to AI-powered attacks. The forward-looking specialism that most practitioners have not yet invested in.

What it proves: The ability to both attack and defend real AI systems across 13 hands-on scenarios. Prompt injection. LLM vulnerability exploitation. AI threat modelling. AI forensics. AI supply chain security. This is the first practical AI security certification available on any platform.

The exam: 13 hands-on scenarios. Offensive and defensive AI security across real AI systems.

Preparation path: AI Security path, 25 rooms covering the full offensive and defensive AI security landscape.

Discount: Premium subscribers receive 15% off.

Explore AI1

Which Certification Path Is Right for You?

If you are a complete beginner

Start with SEC0. Complete it, then move to SEC1. The bundle saves you money and takes you through both foundational credentials in the most cost-effective way. After SEC1, you will know which direction appeals to you: blue team or red team. Then choose SAL1 or PT1 accordingly.

Your path: SEC0 → SEC1 → SAL1 or PT1

If you want a SOC analyst or blue team career

Start with SEC1 if you do not have IT foundations. Go straight to SAL1 preparation if you do. The SOC Level 2 path is your preparation route for SAL2. Once you are in a Tier 1 role, SAL2 is the natural progression to Tier 2.

Your path: SEC1 → SAL1 → SAL2

If you want a penetration testing or red team career

Start with SEC1 to validate your foundational knowledge. Then work through the Jr Penetration Tester path and sit PT1. This is the right first step before OSCP. After PT1 and some professional experience, AI1 extends your offensive capability into the fastest-growing attack surface in the field.

Your path: SEC1 → PT1 → AI1

The Full Certification Reference Table

FAQ

Which cyber security certification has the best practical labs? SAL1 and PT1 are the most practically validated entry-level credentials available. SAL1 puts you inside a live SOC simulator for the exam: real alerts, real tooling, graded incident reports. PT1 is a 48-hour live engagement across web, network, and Active Directory targets with a graded professional report. Both test whether you can actually do the work, not whether you can describe it.

What cyber skills are most in demand for 2026? SOC analysis and threat detection, penetration testing across web and Active Directory environments, cloud security, AI security, and incident response. TryHackMe's certification ladder maps directly to these: SAL1 and SAL2 for detection and response, PT1 for penetration testing, AI1 for AI security. The demand is not for people who have studied these areas. It is for people who can demonstrate they can execute them.

Are TryHackMe certifications worth it? They are worth it for a specific reason: they are practical exams that produce evidence of ability rather than knowledge. SAL1 is backed by Accenture and Salesforce. SAL2 is endorsed by NCC Group. PT1 is recognised as a direct preparation credential for OSCP. These are not paper qualifications. They are proof that you can operate under exam conditions in a live environment. For hiring managers who can evaluate technical ability, that is worth considerably more than a multiple choice pass.

Is a cyber security degree worth it in 2026? A degree provides structured academic grounding and may be required for certain government and regulated sector roles. But most cyber security employers in 2026 weight certifications and demonstrated practical ability over formal degrees. The practitioners who get hired fastest are those with a combination of practical credentials, a visible public profile showing consistent lab work, and the ability to talk specifically in a technical interview about what they have done. A degree without those things is less valuable than most people expect. Those things without a degree are increasingly sufficient.

What cyber security career path should I choose? It depends on whether you want to detect attacks or run them. Blue team work, which covers SOC analyst, incident response, threat hunting, and DFIR, is the most accessible entry point with the largest hiring pipeline. Red team work, which covers penetration testing and offensive security, has a higher technical bar at entry but strong demand and excellent compensation. Both are valid. The right answer is which one you will sustain the motivation to practise consistently over twelve to eighteen months. Start with TryHackMe's free account and see which type of room you keep returning to.

What cyber security salary can I expect at entry level in 2026? SOC Tier 1 analyst roles typically start at $55,000 to $75,000 in the US. Junior penetration tester roles start at $65,000 to $95,000. Both increase significantly with experience and practical credentials. SAL1 and PT1 signal readiness in a way that accelerates hiring decisions and starting salary negotiations because they provide evidence a hiring manager can evaluate, rather than a certificate they have to take on faith.

Knowing what Kerberoasting is and being able to execute it fluently under engagement pressure are two different things. The gap between them is closed by one thing: lab repetition.

Active Directory is the attack surface that defines senior offensive security work. It is the backbone of 90% of enterprise networks worldwide. Compromise it and you own the organisation's entire identity infrastructure. That is why AD techniques dominate OSCP and CRTO exams, appear in almost every red team engagement, and are the area where most junior penetration testers are weakest when they walk into their first interview.

This guide is not about what the attacks are. It is about how to practise them in a structured, progressive way that builds the automatic execution that real engagements require.

Why Do Most Practitioners Underinvest in AD Lab Practice?

Because AD lab setup is genuinely hard. A realistic Active Directory environment requires at minimum a domain controller, one or more victim machines, and network configuration that allows the attacks to run as they would in a real environment. On local hardware, that means Windows Server licences, significant RAM, and hours of configuration before you can start practising.

TryHackMe solves this completely. The Jr Penetration Tester path includes a dedicated nine-room Active Directory module with a fully configured, multi-host AD lab environment in the browser. No Windows Server licence. No VM configuration. No network setup. Open a room and you are inside a live domain with real attack tooling pre-installed. The module covers the full foundational attack chain: AD basics and authentication, enumeration, breaching, credential harvesting, and lateral movement between hosts.

For practitioners who want a persistent local environment after building foundations on TryHackMe, the section on local lab setup is at the end of this guide. Start with TryHackMe.

How Should You Structure Your AD Lab Practice?

The difference between knowing AD attack techniques and being proficient with them under real engagement pressure comes down entirely to lab time. The most effective structure is four progressive stages, each with a clear competency target before moving on.

Stage 1: Enumeration Only

Before you run any attacks, practise enumeration until it is automatic. The goal of this stage is to be able to fully map an AD environment using BloodHound and native tooling without thinking about the commands.

BloodHound uses graph theory to visualise relationships within AD: users, computers, groups, permissions, and the attack paths between them. Run SharpHound to collect the data, import it, and work through the pre-built queries: Shortest Paths to Domain Admins, Kerberoastable Users, AS-REP Roastable Users, Dangerous Rights for Domain Users. This single "Shortest Path to Domain Admins" query has ended countless engagements in under an hour for experienced operators.

Do this on every new lab environment before doing anything else. Make enumeration the habit, not an afterthought.

Competency target: Given a domain user and a live AD environment, identify all Kerberoastable accounts, AS-REP Roastable accounts, and at least one attack path to domain admin within fifteen minutes without referring to notes.

Stage 2: Credential Attacks

With a BloodHound map of the environment, practise credential harvesting against the targets it identifies.

Kerberoasting: Request TGS tickets for all accounts with SPNs. Crack offline with Hashcat. Prioritise accounts where BloodHound shows a path to higher privilege.

bash

# Request all available TGS tickets

.\Rubeus.exe kerberoast /outfile:hashes.txt

# Crack with Hashcat

hashcat -m 13100 hashes.txt rockyou.txt

AS-REP Roasting: Identify accounts with preauthentication disabled. Extract and crack their AS-REP responses.

bash

python3 GetNPUsers.py target.local/ -usersfile users.txt -format hashcat -outputfile asrep.txt

Competency target: Given a BloodHound output identifying Kerberoastable and AS-REP Roastable accounts, extract and crack at least one hash to a plaintext credential within thirty minutes.

Stage 3: Lateral Movement

With credentials or hashes in hand, practise moving from your current foothold to other machines in the network.

Pass-the-Hash: Use NTLM hashes to authenticate without knowing the plaintext password.

bash

python3 psexec.py -hashes :8846f7eaee8fb117ad06bdd830b7586c administrator@10.10.10.5

Spray-and-check with NetExec: Identify which hosts your current credentials work on.

bash

nxc smb 10.10.10.0/24 -u administrator -H 8846f7eaee8fb117ad06bdd830b7586c

Competency target: Given a cracked hash from Stage 2, identify at least two hosts where it provides access and establish a session on both.

Stage 4: Full Kill Chain (No Hints)

Run the entire attack chain from domain user to domain admin without guidance. Enumerate the environment, identify attack paths, harvest credentials, move laterally, escalate privileges, execute DCSync.

This is the stage most practitioners skip too early. CRTP candidates who succeed report 3 to 4 weeks of focused lab time where they documented every attack path like a battle plan and repeated the chain until mind-mapping and repetition made the concepts automatic. That repetition is what produces automatic execution under exam and engagement pressure.

Competency target: Enumerate a live AD environment, identify a viable attack chain, and reach domain admin without hints, in under two hours.

The Progressive Practice Reference Table

Do You Need a Local Lab?

Not to start. TryHackMe's browser-based AD module covers Stages 1 through 3 thoroughly. The capstone challenges in the Jr Penetration Tester path provide Stage 4 practice in unguided format.

A local lab becomes valuable when you want persistent, custom environments you control completely: additional machines, specific misconfigurations, or the ability to practise with C2 frameworks at Stage 4 and above. Game of Active Directory (GOAD) is the community standard for local multi-domain lab setup and deploys a realistic multi-machine environment using Vagrant and VirtualBox. It is a meaningful time investment. Do it after you have completed Stages 1 through 3 in TryHackMe's guided environment.

FAQ

What is a red team vs blue team exercise? A red team exercise is a simulated attack conducted against an organisation's real systems with explicit permission, designed to test whether defences hold against a realistic adversary. The blue team is the organisation's defenders who monitor for and respond to those attacks. In a combined exercise, both teams operate in parallel - the red team attacks while the blue team tries to detect and contain the activity. The findings from both sides inform security improvements that neither could produce independently.

How do I start learning red teaming from scratch? Build penetration testing foundations first. Red teaming is an advanced discipline that sits on top of solid offensive fundamentals across web application exploitation, network penetration, and Active Directory attacks. TryHackMe's Jr Penetration Tester path builds those foundations systematically across 89 rooms and 17 modules. Complete it, sit PT1, and then move into the Red Teaming path for tradecraft: C2 frameworks, OPSEC, evasion, and advanced AD techniques.

How do I learn exploit development for beginners? Exploit development starts with understanding how memory works: stack structure, buffer overflows, instruction pointer control, and shellcode execution. The prerequisite skills are C programming and a basic understanding of x86 assembly. TryHackMe's Jr Penetration Tester path covers buffer overflow fundamentals that establish the mental model before moving into more advanced exploitation. From there, the Seeley series of resources and practice on intentionally vulnerable binaries builds the deeper skills.

What are the best Windows security courses for Active Directory attacks? TryHackMe's Jr Penetration Tester path is the most structured browser-based option, covering the full AD attack chain across a dedicated nine-room module rebuilt for 2026. For mid-level practitioners targeting certification, CRTO from Zero-Point Security is the most practically oriented credential for enterprise AD tradecraft and C2 operation. CRTP from Altered Security covers AD attack paths in depth and is a strong stepping stone between junior-level foundations and CRTO. All three work in sequence.

Threat hunting is not a single tool. It is a workflow that draws on multiple data sources, query languages, and investigative techniques simultaneously. Splunk and Wazuh are the two most commonly deployed open-source and enterprise SIEM platforms in SOC environments, and understanding how to use both is the practical skill set that separates entry-level analysts from Tier 2 investigators.

61% of organisations cite staffing as their top threat-hunting barrier. The analysts who close that gap fastest are the ones who practise with real tools on real data before they walk into a SOC environment for the first time. This guide covers what threat hunting with Splunk and Wazuh actually looks like, with the specific queries and techniques you need to build.

What Is the Difference Between Splunk and Wazuh?

Both are SIEM platforms. They serve different contexts and complement each other rather than compete.

Splunk is the enterprise standard. It ingests log data from across an entire organisation, indexes it, and makes it searchable through SPL (Search Processing Language). Splunk Enterprise Security adds correlation searches, risk-based alerting, and threat intelligence integration on top. It is the SIEM you will encounter most frequently in large enterprise and MSSP environments. Splunk's dominance in enterprise security operations is built on SPL: every investigation, detection, and dashboard in Splunk Enterprise Security is ultimately a search written in SPL.

Wazuh is the open-source alternative. It combines SIEM, XDR, and endpoint detection capability in a single deployable platform: a manager that receives logs, a set of built-in detection rules, file integrity monitoring, active response capability, and a dashboard built on the Elastic Stack. It is what you encounter in smaller organisations, home labs, and SOC training environments - and it is increasingly deployed alongside Splunk for endpoint-specific detection that Splunk's log ingestion does not cover natively.

In a combined deployment, Wazuh agents collect and pre-process endpoint data, and Wazuh alerts are forwarded to Splunk for correlation with other log sources. Understanding both is how you cover the full detection surface.

How Do You Hunt Threats in Splunk?

Threat hunting in Splunk is hypothesis-driven SPL. You form a hypothesis about attacker behaviour, translate it into a query that tests for evidence of that behaviour, and investigate what comes back.

The six SPL commands that cover the majority of SOC investigation and detection work are: stats (aggregate and count events by field values), eval (compute new fields and boolean expressions), rex (extract fields from unstructured text), transaction (group related events into sessions), lookup (enrich events with external data), and where (filter using eval-style boolean expressions). Mastering these six before learning the full SPL command set gives you the tools to handle 90% of real investigation scenarios.

Here are the hunt queries that matter most.

Hunting brute force authentication:

spl

index=auth sourcetype=*ssh* OR sourcetype=*windows* action=failure

| bucket _time span=5m

| stats count by src_ip, _time

| where count > 10

| sort -count

Buckets failed authentication events into 5-minute windows. More than 10 failures from the same source IP in 5 minutes is a brute force indicator.

Hunting lateral movement via Windows event logs:

spl

index=wineventlog EventCode=4624 Logon_Type=3

| stats count by src_ip, dest, user

| where count > 5

| sort -count

Event ID 4624 with Logon Type 3 is a network authentication. Multiple network logons from one source to multiple destinations in a short window indicates lateral movement.

Hunting suspicious PowerShell execution:

spl

index=wineventlog EventCode=4688 CommandLine="*-EncodedCommand*" OR CommandLine="*-NonInteractive*" OR CommandLine="*-WindowStyle Hidden*"

| table _time, host, user, CommandLine

| sort -_time

These PowerShell flags are consistently associated with malicious execution: encoded commands hide payload content, non-interactive and hidden window flags suppress any visible output.

Hunting C2 beaconing via DNS:

spl

index=dns

| bucket _time span=1h

| stats count by src_ip, query, _time

| where count > 50

| sort -count

High-frequency DNS queries to the same domain from the same source host are a classic C2 beaconing indicator. Fifty queries per hour is a conservative threshold - tune based on your environment's baseline.

As one practitioner noted: instead of reviewing the entire dataset, refine it step by step. Proper time scoping often makes the difference between efficient investigation and chaos. Always specify an explicit time range before expanding scope.

How Do You Hunt Threats in Wazuh?

Wazuh detection is rule-based. Each rule maps to a specific log pattern and fires an alert when that pattern appears in monitored data. Threat hunting in Wazuh means two things: reading and tuning existing rules, and writing new rules for behaviours the defaults do not cover.

Reading Wazuh alerts. Every Wazuh alert has a rule ID, a severity level (0 to 15), a description, and the raw log that triggered it. Severity 7 and above is where SOC attention should start. The Wazuh dashboard lets you filter by rule ID, agent (the source host), and time range.

Key rule categories for threat hunting:

• Rule group authentication_failures: Covers failed logins across SSH, Windows, and web applications. High volumes from the same source signal brute force.
• Rule group syscheck: File integrity monitoring. Any unexpected modification to system binaries, configuration files, or startup locations is a persistence indicator.
• Rule group rootcheck: Checks for known rootkit signatures and suspicious process behaviour.
• Rule group windows: Windows Security event detection covering logon events, process creation, privilege use, and service installation.

Writing a custom Wazuh rule for suspicious PowerShell parent-child relationships:

xml

<rule id="100200" level="12">

<if_sid>61603</if_sid>

<field name="win.eventdata.parentImage" type="pcre2">(?i)\\(winword|excel|outlook)\.exe</field>

<field name="win.eventdata.image" type="pcre2">(?i)\\powershell\.exe</field>

<description>Office application spawning PowerShell - possible macro execution</description>

<mitre>

<id>T1566.001</id>

</mitre>

</rule>

This fires when PowerShell is spawned by an Office application, a common macro-based malware execution pattern.

SOC analyst projects that create or tune Wazuh rules for suspicious parent-child process relationships, odd PowerShell command lines, or unusual persistence mechanisms, combined with dashboards that visualise events and drill into alerts, closely align with what enterprise EDR platforms like CrowdStrike, Microsoft Defender, and SentinelOne surface. Building this in a lab environment builds directly transferable skills.

How Does Wireshark Fit Into Threat Hunting?

Splunk and Wazuh operate on log data. Wireshark operates on packet data. They answer different questions.

SIEM logs tell you what happened at the operating system and application layer: which processes ran, which accounts authenticated, which files changed. Wireshark tells you what happened at the network layer: exactly what bytes were transmitted, how connections were established, and whether the traffic matches the protocol it claims to be.

Wireshark becomes essential in threat hunting when:

• A Splunk or Wazuh alert surfaces a suspicious outbound connection. The SIEM tells you a connection occurred. Wireshark tells you what was in it.
• DNS logs suggest C2 beaconing. Wireshark confirms whether the query volume, payload size, and interval are consistent with automated beaconing versus legitimate traffic.
• An alert suggests data exfiltration. Wireshark shows the exact bytes transferred, the destination, and whether the traffic is encrypted in a way that is consistent with the destination.

The practical workflow: Splunk identifies the suspicious host and time window. You pull a PCAP from that window (via network tap, Zeek, or Security Onion) and open it in Wireshark with the source IP filter applied. The SIEM and Wireshark together give you the full picture that neither provides alone.

The Core Hunt Techniques Reference Table

How Do You Practise These Skills Without a Live SOC Environment?

TryHackMe's SOC Level 1 path covers Splunk, Wazuh, and Wireshark in guided, hands-on lab rooms with real log data and pre-configured environments. You are not reading about SPL. You are writing queries against actual Windows event logs, actual network captures, and actual Wazuh alerts in a live environment that runs in your browser.

The Threat Hunting module extends this into hypothesis-driven investigation: forming a hunt hypothesis, selecting the right data sources, writing the queries, and documenting findings in professional format. Every room in both puts you inside the workflow described in this guide.

The most effective way to build speed with SPL specifically: practise with a specific query pattern until it is muscle memory, then move to the next. The analysts who are most effective in Splunk are not the ones who know the most SPL commands but the ones who have a library of proven patterns they can adapt quickly to new investigation scenarios. Build the library. The speed follows.

FAQ

What does a blue team do in cyber security? The blue team is the defensive side of a security operations function. Blue team analysts monitor networks and endpoints for threats, investigate alerts from SIEM platforms like Splunk and Wazuh, respond to confirmed incidents, and tune detection rules to improve coverage over time. The work spans alert triage at Tier 1 through deep forensic investigation at Tier 2 and above, threat hunting at senior levels, and detection engineering for the most experienced practitioners.

How do I practise log analysis for cyber security? Start with a SIEM platform and real log data. TryHackMe's SOC Level 1 path provides both: guided rooms with pre-loaded Windows event logs, network captures, and Splunk search environments. The specific skills to practise are: identifying which log sources contain evidence for a given hypothesis, writing queries that filter those logs down to the events you need, and reading event fields accurately enough to determine whether an alert is a true or false positive.

How do I use Wireshark for network analysis? Wireshark captures and dissects network traffic at packet level. The most important skill is filtering: use the display filter bar to narrow from millions of packets to the specific traffic you are investigating. Common useful filters: ip.addr == 10.10.10.5 to isolate a specific host, dns to view only DNS traffic, http.request to view only HTTP requests, tcp.flags.syn == 1 && tcp.flags.ack == 0 to see connection initiations. Follow a TCP stream (right-click any packet, select Follow > TCP Stream) to reconstruct the full conversation between two hosts. Use Statistics > Conversations to quickly identify the highest-volume connections in a capture.

What is the best way to practise network traffic analysis best practices? The most effective method is investigating real PCAP files from known attack scenarios. Pair Wireshark analysis with Zeek log review: Zeek transforms raw traffic into structured connection, DNS, HTTP, and SSL logs that are faster to query than reading individual packets. TryHackMe's network security monitoring content in the SOC Level 1 path provides guided practice across both tools against real attack traffic.

Cloud security is one of the fastest-growing and best-paid specialisations in cyber security right now. Cloud security spending is projected to grow 18% annually, driven by increasing cyber threats and multi-cloud adoption. Over 90% of organisations face IT skills shortages, and cloud security professionals are among the hardest roles to fill. That gap between demand and supply is your opportunity.

The question is not whether cloud security is worth pursuing. It clearly is. The question is how to get there from where you are starting right now.

What Does a Cloud Security Career Actually Look Like?

Cloud security is not a single job. It is a collection of roles that sit at the intersection of cloud infrastructure and security operations. The work differs significantly depending on which role you are in.

Cloud Security Engineer is the most common destination role. You design, implement, and maintain security controls across cloud environments: IAM policies, network segmentation, encryption, logging and monitoring, and incident response capability. You are the person who makes sure the cloud infrastructure is configured securely and stays that way. Entry-level cloud security engineers earn $85,000 to $110,000 in the US, with senior engineers clearing $200,000 or more at major tech firms.

Cloud Security Analyst sits closer to SOC operations. You monitor cloud environments for threats, investigate alerts from cloud-native security services like AWS GuardDuty, Azure Defender, and GCP Security Command Center, and respond to incidents in cloud infrastructure. The detection and response skills you build in SOC work transfer directly here.

DevSecOps Engineer embeds security into the software delivery pipeline. Infrastructure as code scanning, container image security, CI/CD pipeline security controls, and shift-left practices that catch misconfigurations before they reach production. Roles that integrate DevSecOps practices are among the most in-demand cloud security positions in 2026, with top salaries reaching $225,000 annually.

Cloud Penetration Tester assesses cloud environments offensively: testing IAM misconfigurations, storage access controls, network exposure, container escape paths, and attack paths through cloud-native services. Cloud penetration testing is increasingly expected as a core skill in enterprise security assessments, not just a specialist engagement type.

What Cyber Skills Are Most in Demand for Cloud Security in 2026?

The skills that appear most consistently in cloud security job postings are specific. Here is what employers are actually looking for.

Identity and Access Management (IAM). IAM misconfigurations are the most common cloud vulnerability and the most common initial access vector in cloud breaches. Understanding how to write least-privilege IAM policies, audit existing permissions, manage service accounts and non-human identities, and detect over-permissioned roles is the foundational cloud security skill. This applies across AWS (IAM policies, roles, permission boundaries), Azure (RBAC, Entra ID, service principals), and GCP (IAM bindings, service accounts).

Misconfiguration detection and remediation. Public S3 buckets, exposed storage containers, overly permissive security groups, publicly accessible databases: cloud misconfigurations are responsible for a significant proportion of cloud breaches and they are detectable with the right tooling and methodology. Cloud Security Posture Management (CSPM) tools automate detection at scale. Understanding what they find and how to fix it is the operational skill.

Container and Kubernetes security. Container adoption has made Kubernetes security a core requirement in most cloud security roles. Pod security contexts, network policies, RBAC for Kubernetes, container image scanning, and runtime threat detection are all expected knowledge. Cloud security engineers must protect ephemeral workloads and container images, with runtime scanning and image signing becoming essential skills in 2026.

Infrastructure as Code (IaC) security. Terraform and CloudFormation are how cloud infrastructure is built in most enterprise environments. Scanning IaC templates for misconfigurations before deployment, using tools like Checkov or tfsec, is the shift-left security practice that DevSecOps roles require.

Cloud-native threat detection. AWS CloudTrail, Azure Monitor, GCP Cloud Logging, and the native security services built on top of them (GuardDuty, Defender for Cloud, Security Command Center) are the primary detection tools in cloud environments. Knowing how to configure them, what they capture, and how to investigate their alerts is essential for cloud security analyst and engineer roles.

What Qualifications Do You Need for Cloud Security?

The honest answer: foundational cloud knowledge first, security layer second.

You cannot secure a cloud environment you do not understand. Before specialising in cloud security, spend time with at least one major cloud platform at the foundational level. AWS Cloud Practitioner, Azure Fundamentals (AZ-900), or GCP Cloud Digital Leader all cover the architectural concepts that make cloud security controls meaningful rather than abstract.

Once the foundation is in place, the security-specific credentials matter. AWS Certified Security Specialty saw demand surge 73% in 2025 and commands a significant salary premium for cloud security roles. Microsoft SC-200 (Security Operations Analyst) and AZ-500 (Azure Security Engineer) are the equivalent Azure credentials. GCP Professional Cloud Security Engineer sits at $159,135 average salary, with GCP Cloud Network Engineer at $163,198 - reflecting the scarcity of GCP security specialists.

ISC2 recommends building a layered credential roadmap: foundational security (CompTIA Security+ or ISC2 CC), then operational cloud security skills, then CCSP (Certified Cloud Security Professional) as the vendor-neutral cloud security milestone that validates multi-cloud readiness. Pair CCSP with one platform-specific credential for the strongest hiring signal.

For hands-on preparation, TryHackMe's cloud security rooms cover the practical skills that certifications test in a browser-based lab environment. No cloud account setup required. The SOC Level 1 path builds the detection and investigation foundation. TryHackMe's cloud security rooms extend this into cloud-specific monitoring, IAM, and misconfiguration identification.

Cloud Security Career Paths: Roles, Skills and Salaries

Which Cloud Platform Should You Focus on First?

AWS still dominates with 30 to 32% of global cloud infrastructure market share, making it the broadest global job market for most roles. Azure is closing the gap fast, particularly in enterprise environments, finance, healthcare, and government - and is the stronger choice if you are targeting large enterprises or operating in Europe. GCP holds 10 to 12% of market share but the roles that require it tend to pay more, reflecting genuine scarcity of GCP security specialists.

The practical advice: pick one platform, go deep, then expand. AWS usually offers the broadest global job market; Azure is strong with large enterprises using Microsoft tools; GCP is popular for data and ML roles. The core concepts - IAM, network security, logging, encryption - transfer across all three platforms. Start with the one most common in your target job market.

FAQ

What cyber skills are most in demand for cloud security in 2026? IAM configuration and auditing, cloud misconfiguration detection, container and Kubernetes security, Infrastructure as Code scanning, and cloud-native threat detection using platform tools like AWS GuardDuty, Azure Defender, and GCP Security Command Center. These appear most consistently across cloud security job postings in 2026 and represent the skill gaps organisations are most actively trying to fill.

What are the salary expectations for entry-level cloud security roles in 2026? Entry-level cloud security analyst roles typically range from $75,000 to $110,000 in the US. Cloud security engineers at entry level earn $85,000 to $110,000. AWS certifications add $10,000 to $25,000 to compensation on average. Salary varies significantly by location, with San Francisco, Seattle, New York, and Northern Virginia commanding premiums above national averages.

What cyber security career path should I choose if I am interested in cloud? If you want to work defensively, target Cloud Security Analyst first. The SOC skills you build - SIEM, log analysis, incident response - transfer directly into cloud security operations. If you have a development or infrastructure background, DevSecOps or Cloud Security Engineer is the natural path. If you want to work offensively, Cloud Penetration Tester is the destination, but build standard penetration testing foundations through the Jr Penetration Tester path first before specialising in cloud attack techniques.

Do you need a computer science degree to get into cloud security? No. Many successful cloud engineers come from IT support, networking, software development, or even unrelated fields. Employers care far more about what you can demonstrate than where you went to school. A combination of platform certifications, security credentials, and documented hands-on lab work is what gets you hired in cloud security, not a degree.

How long does it take to start a career in cloud security? With consistent effort, most people build enough foundational cloud and security knowledge to target entry-level cloud security analyst roles within 12 to 18 months. The path: cloud fundamentals (two to three months), security foundations (two to three months), cloud security specialisation including one vendor-specific credential (four to six months), plus consistent hands-on practice throughout. The hands-on element is what separates candidates who get interviews from those who do not.