Cybersecurity roadmap for beginners (2027)

Six stages from zero to a first security role, with what to learn at each one and how you know you're done, written by an intern a year in.

A cybersecurity roadmap has six stages: foundations, core concepts, hands-on practice, picking a lane, proving it, and getting the first role. The order matters more than the speed. Most people who get stuck skipped stage one and went straight to stage three, because stage three is the fun part.

I started this a year ago. I'm an intern, not a senior engineer, and this is the roadmap I'd hand to myself on day one. It's short on tool lists and long on "how do you know you're done", because that was the question nobody answered for me.

Before you begin, read Komal's post on whether cybersecurity is an entry-level field. It sets the expectation this roadmap is built on: security is a layer on top of something, so the "something" has to be learned first.

Stage 1 of the cybersecurity roadmap: how computers, networks and the web actually work

This is the stage everyone wants to skip and the one that decides everything after it.

Security is the study of how systems fail, and you can't see a failure in a system you don't understand. Every attack you'll learn about, from phishing to prompt injection, is a normal mechanism used for an abnormal purpose. If you don't know the normal, the abnormal is invisible.

What to learn:

How a computer works. What a process is, what memory is, what the operating system does between a program and the hardware, what a file permission is. The mental model, not the degree.
How a network works. IP addresses and ports. What DNS does. What TCP does that UDP doesn't. What happens, step by step, when you type a URL and press enter. That's a classic interview question because it touches DNS, TCP, TLS, HTTP and the browser in one sentence.
How the web works. HTTP requests and responses. Headers. Cookies and why they exist. What a session is. What the same-origin policy protects. What JavaScript in a page can and can't do.
Linux command line. Not "I've used Ubuntu". cd, ls, cat, less, grep, pipes, editing a file in the terminal, chmod, reading logs. A VM on your laptop is enough.
One scripting language. Python. Enough to read a file, parse some text, make an HTTP request, and loop over a list. Not enough to build a web framework.

How you know you're done: you can explain, out loud and without notes, what happens when you log into a website, from DNS lookup to the cookie landing in your browser. You can find the line in a log file that mentions a specific IP address without googling the command. You can write a Python script that fetches a page and prints every link in it.

If you can't do those three things, stay here. It's not wasted time.

Stage 2: core security concepts

Now you have the normal. This stage is about the vocabulary for the abnormal.

CIA. Confidentiality, integrity, availability. Every security control protects one or more of these, and every attack damages one or more. When you can name which one a given control protects, you've understood the control.
Threat modelling. Four questions: what are we building, what can go wrong, what are we going to do about it, did we do a good job? The habit is asking "who'd attack this, what would they gain, and where's the trust boundary they'd have to cross?" before anything else.
Authentication and authorisation. They're different words for a reason. Authentication is proving who you are. Authorisation is what you're allowed to do once you've proven it. Learn passwords, hashing, multi-factor, sessions, tokens and passkeys at the level of "what does each one actually stop". Yash's post on passkeys, passwords and 2FA is the version of this I wish I'd read first.
Cryptography at concept level. Symmetric versus asymmetric. What a hash is and why it's one-way. What a signature proves. What TLS is doing when the padlock appears. Not the maths: which tool solves which problem, and what breaks when someone picks the wrong one.
The common vulnerability classes. The OWASP Top 10 at owasp.org is the standard list for web. Read it once for the names; you'll meet each one properly in stage three.

How you know you're done: someone describes a small system to you, say a login form that emails a reset link, and you can list three things that could go wrong with it and name the trust boundary each one crosses. You can explain why hashing a password is not the same as encrypting it. You can say what a JWT is and why Kushagra's point that a JWT can't be logged out is true.

Stage 3: hands-on, where the concepts become skills

Stage three is where you find out which parts of stage two you actually understood.

The platforms I'd use, in roughly this order:

TryHackMe at tryhackme.com. Guided rooms with a browser-based machine. It holds your hand, which is exactly what you want at the start. Do the beginner paths, then the ones that match the lane you're leaning towards.
PortSwigger Web Security Academy at portswigger.net/web-security. Free, written by the people who make Burp Suite, and the best structured web security course I've found. Each lab is one vulnerability class, with the theory first and a target you're authorised to attack. If you only do one thing in this stage, do this.
Hack The Box at hackthebox.com. Less hand-holding, closer to the real thing. Start with the retired machines that have write-ups, so you can check your reasoning when you get stuck.
CTFs. Capture-the-flag competitions. Find beginner-friendly ones, join with a friend, and expect to solve very little the first time. The value is seeing how other people think when the write-ups come out afterwards.

Two rules. Only attack things you're authorised to attack: the labs above, your own machines, nothing else. And when you get stuck, read the solution, understand it, then redo the lab from scratch without it. Copying a solution teaches you nothing. Reproducing it does.

Mix in small practical skills too. Finding the secrets already sitting in a git history is a five-minute skill that comes up constantly in real work and that most beginners never learn because it isn't on any syllabus.

And do the Daily Adversary. Three questions a day sounds trivial. It isn't. Recognition fades if you don't exercise it, and a daily habit is the cheapest fix.

How you know you're done: you've finished the PortSwigger labs for the main vulnerability classes (injection, authentication, access control, XSS, CSRF, SSRF) and can explain each mechanism without looking it up. You've rooted a few Hack The Box machines and done one CTF. You're never fully done with this stage; you just stop being a beginner at it.

Stage 4: pick a lane

Security is not one job. By the end of stage three you'll have noticed which parts pulled you in and which you did because you had to. Follow that.

Lane	What the work looks like	Lean this way if
Offensive (pentest, red team)	Finding and demonstrating weaknesses in systems you're authorised to test, writing reports	You liked the labs and CTFs most and enjoy the puzzle
Defensive / SOC	Monitoring, detection, log analysis, incident response	You liked reading logs and working out what happened
Cloud security	Identity, permissions, configuration and architecture in AWS, Azure or GCP	You enjoyed the infrastructure side and the "how is this wired together" questions
AppSec	Reviewing code, threat modelling features, working with developers	You already write code, or want to, and like reading other people's
AI security	Prompt injection, data leakage through models, agent permissions, evaluating LLM apps	The stage two threat modelling clicked and you're curious about new attack surfaces

AI security is the newest lane and the one this site spends the most time on. If it interests you, Kushagra's prompt injection explainer is the starting point, and the AI Audit shows what evaluating an LLM app actually involves.

The choice isn't permanent; people move between lanes and the foundations transfer. The reason to pick now is that "security generalist" isn't an entry-level job title, and a focused stretch in one lane gets you further than the same time scattered across five.

How you know you're done: you can say in one sentence which lane you're going for and why, and your practice has become lane-specific. If you can't choose, pick the one whose labs you kept going back to.

Stage 5: prove it

Nobody can see what's in your head. Stage five turns what you know into things other people can look at.

Write-ups. Every lab, machine or CTF challenge you finish, write it up. What the target was, what you tried, what worked, what you'd do differently. Plain language, anything with a URL. Writing is half the skill in this field, and these are the only evidence a hiring manager has that you can think.
A home lab. A couple of VMs on your own machine: one attacker, one or two targets you've built for the purpose. Going defensive, add log collection and try to detect your own attacks. Going cloud, a free-tier account and a deliberately misconfigured bucket you then fix and document. Keep it small enough that it actually exists.
A GitHub. Scripts, lab configs, write-ups. It doesn't need to be impressive. It needs to be real and recent.
One certification, if it opens a door. CompTIA Security+ is the common first one and the one that most often appears on entry-level listings. I'd only do it if the roles you're applying for ask for it. It proves breadth, not depth, and won't substitute for stages three and five. Syllabi, formats and costs change, so check the vendor's site rather than a forum post from three years ago.

How you know you're done: you have a URL you'd put at the top of a CV. Someone who clicked it would see write-ups, a lab and code, and know which lane you're in.

Stage 6: get the first role

The honest part first. The first role is the hardest step, and the timeframe varies with how much time you can give it, whether you're coming from an IT or development background, and where you live. I'm not going to give you a number of months because I'd be making it up.

Where the first roles usually are: SOC analyst, junior pentester, security intern, IT roles with a security component, and junior developer roles on teams that care about security. A help-desk or sysadmin role that lets you touch security work is not a detour; it's stage one with a salary.

What helps, from what I've seen in my own year:

Apply to roles that describe what you've actually done in stage five, not what you hope to do in three years.
Put the write-ups link above the certifications on the CV. It's the thing that's actually yours.
Talk to people in your lane. Not "can you get me a job" but "what does a day in this role look like". Most people are generous with that question.
Keep up the daily practice and the labs during the search. A gap in your GitHub during the months you were applying is visible.

How you know you're done: someone pays you to do security work, even a small amount of it. Then the roadmap starts again, one level up.

Frequently asked questions

Do I need a degree to get into cybersecurity?

No, but it helps with some employers and some countries' visa rules, so check the roles you actually want. What matters more is whether you can do stages one through five and show it. A degree is one way through stage one, not the only one.

Which programming language should I learn first for cybersecurity?

Python. It's readable, it's what most security tooling and tutorials use, and it covers scripting, automation and simple web requests. In the AppSec lane you'll also need to read whatever your team ships in, but that comes later.

Should I get Security+ before I start applying?

Only if the roles you're targeting list it. It's the common first certification and it opens some doors, especially in larger organisations. It doesn't replace hands-on practice or a portfolio, and plenty of people get a first role without it.

How long does this roadmap take?

I don't know, and anyone who gives you a confident number is guessing. It depends on your starting point, your hours per week and your lane. What I can tell you is that skipping stage one to save time costs more time later, every time.

Is AI security a realistic lane for a beginner?

Yes, with the same foundations as everyone else. The attacks are new but the thinking is the same: find the trust boundary, work out what crosses it, work out what a defence costs. Read the prompt injection post, run the AI Audit against something you've built, and write up what you found.

Pick stage one. Open a terminal, type ls, and start. Then come back tomorrow and do three questions so that whatever you learned today is still there next week.