I started my journey into cybersecurity in the late 2000s, without really knowing that there would be a job out there that would pay me to do something I enjoyed. It started as a hobby and gradually turned into a career. I’m thankful for all the opportunities and, more importantly, the people who helped me turn that curiosity into a profession. The cybersecurity community and meetup groups played a huge role in helping me navigate the field when I was starting out.
There were no reels or short videos promising to “become a hacker in 90 days,” no bootcamps with money-back guarantees, and barely any formal degree programs that even used the word “cybersecurity.” I learned by reading forums, experimenting with whatever I had access to at home or at my friends’ homes, breaking things on machines I owned, and being lucky enough to find people willing to answer my dumb questions. I’m sure many people can relate to this.
Years later, the world has changed a lot, and so has the digital landscape. But the question is still relevant: How should I get started in cybersecurity? What do I actually study? Which certifications are worth it? How do I pick a specialization? And what do I do about AI — is it going to take these jobs before I even get one?
In this blog post, I’ll try to answer from my perspective — the thing I actually tell people over coffee.
What’s genuinely different since 2010
The field has definitely become more professionalized and widely recognized. There are now real degree programs, structured bootcamps, and hundreds of certifications covering nearly every specialty. I maintain a list of 500+ cybersecurity certifications. Information that used to take months to find is now just a search away.
That’s also the problem.
A decade ago, the barrier was access to information. Today, the barrier is direction — an overwhelming firehose of courses, roadmaps, and “top 10 certifications you need” posts, most of which are written to sell something rather than genuinely help you. Access stopped being the bottleneck years ago. Figuring out what actually matters is the new challenge.
The attack surface has changed shape too. Cloud, APIs, SaaS sprawl, containers — none of these were default assumptions ten or fifteen years ago. And now there’s a new layer on top of all of it: AI, which is simultaneously a tool practitioners use every day and a new category of technology that itself needs to be secured.
The AI wave, honestly
I’m not going to tell you whether AI is good or bad, or whether it will replace cybersecurity jobs. Two things are happening at once, and conflating them is where much of the anxiety I hear from students comes from.
When I started, one of the first things I had to learn was how to use search engines to find relevant information. We used Google dorks and other search techniques to find information that wasn’t always easy to discover.
Today, AI can do much of that work — but it goes well beyond traditional search functionality.
AI as a tool you’re expected to use. SOC teams are increasingly using AI copilots to help with alert triage. Code review, log analysis, research, and report writing are increasingly happening with an AI assistant in the loop. If you’re entering the field now, not knowing how to work alongside these tools is becoming closer to not knowing how to use a search engine than being an optional bonus skill.
AI as a new thing to secure. Prompt injection, LLM application security, model supply-chain risks, and agentic AI systems that can call tools on your behalf — these represent a genuinely new and rapidly evolving area of security. I wrote a deep dive on the AI and LLM security certification landscape if you want to see how new: most of those credentials didn’t exist eighteen months ago.
What to actually study first
Before tools, before certifications, and before picking a specialization — this is the order that I believe actually holds up:
Networking fundamentals. TCP/IP, DNS, HTTP, and basic routing. You cannot secure, attack, or even meaningfully talk about a system you don’t understand at the network level.
An operating system. Linux especially — become comfortable with the command line, file permissions, processes, and logs. Most security tools, servers, and CTFs assume this baseline and won’t slow down to teach it to you.
How the web actually works. HTTP requests, sessions, cookies, and APIs. A large portion of day-to-day security work — offensive or defensive — touches a web or cloud application somewhere.
One scripting language. Python would be my first choice. Bash and PowerShell are good options too. Not because you need to become a software engineer, but because you need to be able to read, modify, and automate tools rather than just click buttons in them. You don’t need to be an expert in any of these languages. You should, however, be comfortable enough to read, write, understand, and modify code when you need to, and automate a few things yourself.
Core security concepts, before tools. The CIA triad, threat modeling, least privilege, defense in depth, and other foundational security concepts. This is the vocabulary that lets you reason about any new tool, trend, or headline — including AI — without starting from zero every time something new appears.
Tools and trends will keep changing every year. This list won’t.
The people I see stall out are usually the ones who skipped these fundamentals and went straight to tools and certifications without building the foundation underneath them. It eventually shows up — usually during an interview or when they’re asked to solve a problem they’ve never seen before.
Picking a lane
“Cybersecurity” isn’t one job, and one of the biggest mistakes early in a career is treating it like one. Some of the major areas include:
SOC / detection & blue team. Monitoring, triage, and incident response. Detective work — you’re looking for the story hidden in the noise.
Penetration testing / red team. Finding and exploiting weaknesses before someone else does. A builder-and-breaker mindset.
Application security. Securing software as it’s being built — code review, secure design, and working closely with developers.
Cloud security. Securing the infrastructure that increasingly is the company — AWS, Azure, GCP, identity, architecture, and configuration.
GRC — governance, risk and compliance. Policy, audit, risk management, and regulation. It’s less hands-on-keyboard, but more important than many people assume when they’re starting out.
Digital forensics & incident response. What happened, how did it happen, and can you prove it? Part detective, part scientist.
AI/LLM security. The newest area — securing AI systems and applications, or using AI to secure everything else, depending on which side of the field you work in.
Don’t pick a lane based on what’s loudest online right now. At the moment, that’s often red teaming and AI security.
Instead, pick based on the kind of problem that genuinely holds your attention when nobody’s watching.
Try a bit of everything through free labs and CTF challenges available online. You’ll find out pretty quickly which areas you enjoy — and which ones you don’t want to be doing at 11 PM.
Do certifications actually matter?
Yes and no. And the honest version is more useful than either extreme.
An entry-level certification can still be helpful as a way to demonstrate foundational knowledge to HR or hiring managers. Treat your first certification as a way to clear that initial gate, not as the finish line.
If you can demonstrate your skills in other ways — being in the top 10 on a bug bounty platform, having published CVEs, speaking at cybersecurity conferences or meetups, building projects, or contributing to open-source projects on GitHub — those can also demonstrate your capabilities.
Beyond that first certification, pursue certifications that map to the area you’ve actually chosen and that employers hiring for those roles actually ask for — not simply the ones with the flashiest marketing.
And remember that a certification with no visible work behind it is a much weaker signal than one backed by a home lab, CTF placements, technical write-ups, or open-source contributions. Employers increasingly want to see demonstrated skills, not just a logo on a resume.
There’s also a genuinely free way to get started. Several vendors offer legitimate, no-cost foundational certifications. These can be worth doing for the resume line and the confidence they provide before you’re ready to invest money in certifications.
Build proof, not just paper
This is the part people skip and shouldn’t.
A home lab, even a free one. VirtualBox and a couple of vulnerable VMs can teach you more in a weekend than a month of slides.
CTFs, as a low-stakes way to find out whether you actually enjoy this kind of work before committing your career to it.
Write about what you learn. A blog, even a rough one, is both a portfolio and a forcing function. You don’t really understand something until you’ve tried to explain it to someone else.
Use and read open-source security tools, not just polished commercial products. File a bug, write a guide, or ask the author a question. I’ve now interviewed 50+ tool authors on the podcast, and almost none of them started out any differently from where you’re starting now. The community is smaller and more approachable than it might look from the outside.
Internships, bug bounty, volunteer SOC shifts — anything that gives you real exposure before you need a full-time offer to prove yourself.
On the job market, honestly
Entry-level hiring is genuinely more competitive than it was a decade ago. That doesn’t necessarily mean the industry is shrinking — the demand for cybersecurity skills remains broad — but “generic junior analyst” has become a highly competitive entry point.
The answer isn’t simply applying to more job postings. It’s being specific.
“I want to break into cybersecurity” is a sentence that almost nobody can act on.
“I want to work in detection engineering, and here’s a home-lab project where I built a small SIEM pipeline” is a sentence that gives someone something concrete to look at.
Patience, specificity, and visible proof are far more useful than simply increasing the number of applications you send.
Where this leaves you
The tools have changed dramatically. The entry points have multiplied. AI has already changed parts of the job description, and it will continue to do so.
But the core of this work — staying curious, understanding how systems really behave, and being the person still reading the source code, documentation, or RFC at midnight because you genuinely want to know, not because someone assigned it to you — hasn’t moved much.
And I don’t think it will.
Keep your curiosity alive.