← All posts
Careers

"Cybersecurity is not an entry-level field": is that true?

Both sides of the "security is not entry-level" argument, stated fairly, and a founder's answer: it is, if you treat the first job as a systems job.

Is cybersecurity entry level? Yes, for the person who treats their first security job as a systems job. No, for the person who skips the systems and goes straight for the label. That is my whole position, and the rest of this post is me earning it.

I hire for this studio and I mentor people who want in, so I get asked this most weeks, usually after a thread where one camp says "do five years of sysadmin first" and the other says "that's gatekeeping, I got a SOC job out of college". Both are right about something. Here is each side's strongest case.

The strongest case for "not entry level"

Security is a judgement layer on top of systems knowledge. It is not a system of its own.

Someone looks at a web app and says "this session handling is wrong". To say that, they need to know how sessions work, how cookies are scoped, and what a browser will and will not send cross-origin. The security opinion is the last ten percent. The first ninety percent is knowing how the thing runs.

The same shape holds everywhere. You cannot review a cloud IAM policy if you don't know what the service does with the permission. You cannot judge whether an alert is a false positive if you've never run the system that produced it. Defence is comparison against a baseline, and the baseline lives in operations.

The second point this camp makes is the one I find hardest to argue with. Look closely at most junior roles with "security" in the title and you'll find IT or development roles with a security label on top. The junior "application security engineer" is a developer who reads diffs. The junior "security analyst" is a sysadmin who reads logs. The label says what the person protects, not what they do all day.

So the honest version of this argument isn't "you can't start here". It's "you can't start here without also starting somewhere else at the same time".

The strongest case for "yes, it is"

Entry points exist, they're real jobs, and pretending otherwise hurts the field.

SOC tier 1 is the obvious one. Take alerts, triage them against a runbook, escalate what doesn't fit. It is repetitive and has a defined scope, which is exactly what an entry-level job is supposed to be. People learn log formats, alert tooling, and what normal looks like on a network they didn't build. That's systems knowledge, acquired on the job, with a paycheque.

GRC (governance, risk and compliance) is another. Someone has to map a control framework against what the organisation actually does, chase evidence, and write it up. It gets dismissed as "not real security" by people who've never had to explain to an auditor why a control is missing. It teaches you how an organisation works, which is a system too, and arguably the hardest one.

Security awareness and support roles round it out: writing the phishing simulation, being the person who answers "is this email real?" Entry level by any definition, and more important than the title suggests. Rohan's post on why recognition is a perishable skill makes that case.

And the gatekeeping point is fair. "Not entry level" is often said by people who got in through a door that has since closed, to people who are being told to go spend five years doing something else first. That advice is sometimes right. It is also sometimes a way of keeping a field small and familiar, and the field cannot afford to stay small.

Where I land on whether cybersecurity is entry level

The SOC tier 1 analyst who treats the role as "learn how this network, these servers and these identities actually behave" is in a security career. The one who treats it as "click through alerts until I can get the pentester job" is in a holding pattern, and the holding pattern doesn't end, because the pentester job also needs the systems knowledge they skipped.

That's the trap. Not that the entry jobs don't exist, but that they let you stay at the label layer indefinitely if you choose to. Nobody will stop you. The runbook works without understanding. You can triage for three years and never once ask why the alert fired.

So when I interview, the question I care about isn't "have you done security before". It's "pick a system you've touched and tell me how it works, in enough detail that I could break it". Someone who has run a Linux box on the public internet for a year and watched the auth log fill with attempts has more useful instinct than someone with three certificates and no shell history.

The limit: I'm describing what works for a small studio doing hands-on work. A large enterprise SOC or a bank's compliance team may weigh this differently.

What to actually do

Pick one system. Not three. Web, cloud or networks, whichever you can get your hands on most cheaply, and get good at running it, not just reading about it.

For web, that means standing up a small application with real authentication and a real database, hosting it somewhere public, and keeping it alive. For cloud, it means a single account, a few services, a budget alert, and the discipline to understand every permission you grant. For networks, it means a home lab with a firewall you configured yourself and traffic you can capture and read.

Then break what you built, on purpose, in your own lab. Authorised targets only; that is not a legal nicety, it's the whole difference between a practitioner and a liability. PortSwigger's Web Security Academy at portswigger.net/web-security, TryHackMe and Hack The Box all give you targets you're allowed to hit.

Then write it up. Short, honest, in public if you can. What you built, what broke, what you'd do differently. A written record of a working lab is the strongest hiring signal I know of from someone with no job history, because it proves the ninety percent and shows how you think about the ten.

While you're building, keep the judgement layer warm. The Daily Adversary is three security questions a day, made for people doing the systems work who want the security instinct practising alongside it. I wrote about why in the founder's note.

My view is shaped by the hiring I do, not the hiring you may be facing, so: if you got in through an entry-level role, what did that first job actually teach you, and would you tell someone to take it again?

Frequently asked questions

Do I need a degree to start in cybersecurity?

No. What predicts well in interviews is evidence that you've run a system and understood it, which a degree can provide and so can a year of hosting your own project. If a specific employer or visa route requires one, that's a hiring rule, not a statement about the work.

Is SOC tier 1 a dead-end job?

Only if you let it be. It's a dead end for people who learn the runbook and stop. For people who use it to learn how real networks and identities behave, and who ask why each alert fired, it's one of the better starting points, because you're paid to look at a system you didn't build.

Should I get a certification first?

A foundational one can help you pass a recruiter's filter and gives you shared vocabulary. It won't substitute for a lab. If you have to choose between a certificate and three months of running something real and writing it up, I'd pick the lab, and so would most people who'd interview you after that.

How long before I can call myself a security person?

The moment you can explain how a system you've run could be attacked, and what you'd change to stop it, you're doing the work. The title comes later and is mostly a payroll decision.

Careers
Six stages from zero to a first security roleCareers

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.