Breaking into cyber: the path I'd take if I were starting now

I did not start in cyber. My first degree was accounting, and I was a cyber auditor at the Department of Defense Inspector General before I ever built anything. Here is the path I would take if I were starting today.

Most of what gets written about breaking into security is either a certification advertisement or a list so long it reads as impossible. This is the short version, in the order the steps actually matter.

Pick a direction first

"Cybersecurity" is several fairly different careers, and people waste a year studying for the wrong one. Broadly:

• ComplianceVerifying that security exists — auditors, assessors, ISSOs, risk and governance work. Heavy on frameworks, writing and evidence. This is where I started.
• BlueDefending systems — security engineers, analysts, SOC work, vulnerability management, detection. The largest category by a wide margin.
• RedAttacking systems — penetration testing, reverse engineering, exploit development. The most competitive and the hardest to enter cold.
• DFIRDigital forensics and incident response. Works out what happened after something went wrong, and preserves evidence well enough that it survives a lawyer. Sits awkwardly across the others — usually filed under blue, but the work is reactive rather than preventive, and the evidence handling has more in common with my audit years than with engineering. Chain of custody, defensible methodology, writing findings that hold up under challenge.
• ManagementCISO, security director, program management. Not an entry point, but worth knowing it exists so you can aim at it.

If you have no strong pull in one direction, go blue. Defensive work requires you to think offensively anyway — you cannot prioritise a vulnerability without understanding how it would be exploited — so you end up learning a bit of both, and there are far more jobs.

DFIR is the exception worth calling out separately, because people arrive at it sideways. Almost nobody is hired straight into forensics; you get there from blue team work, or from law enforcement, or occasionally from audit. If it appeals, the route is to do detection and response work first and specialise later.

Certifications, honestly

CompTIA Network+ and Security+ are worth having. They prove foundational knowledge and they get you past automated resume filters, particularly for government and contractor roles. A+ helps if you have no IT background at all.

What they do not do is get you hired on their own. A certification says you can pass a test about a subject. Nobody has ever been impressed by one in an interview; they are a floor, not a differentiator.

A degree in anything STEM-adjacent is fine, and it does not need to be in computing. Mine is in accounting, which turned out to matter more than it sounds like it should: SOC 2 is an attestation standard written by accountants and performed by CPAs. Materiality, evidence sufficiency, control testing, management representations — that is audit vocabulary, and I learned it before I learned to write Terraform.

The thing that actually kills candidates

No experience. It is the single reason most people with a cyber degree and three certifications cannot get a first job, and it is entirely fixable before you graduate.

Build something. A laptop, VirtualBox or VMware Workstation, and a few virtual machines is enough to start:

• Stand up a Linux VM and a Windows VM. Create users, assign permissions, lock down directories.
• Harden them against a real benchmark — CIS or a DISA STIG. Not "I turned on the firewall," an actual published baseline.
• Scan them. Wazuh is free and runs as a container, and it covers SIEM, endpoint and vulnerability scanning in one. Nessus Essentials, OpenVAS and Trivy are all free too.
• Read the findings, fix them, scan again. That loop is the job.
• Run containers. Then try to secure them, which is a different problem than securing the host.

Notice that most of that is engineering, not security. That is the point. You cannot protect something you do not understand, and the fastest way to understand a system is to build and break one yourself.

Learn to script

Pick one scripting language and get properly comfortable: PowerShell if you are heading toward Windows environments, Bash for Linux, Python for everything. Knowing a compiled language helps later, but scripting is what you will use on day one.

The reason is simple. Every security job contains a pile of repetitive work — pulling reports, reconciling scan output, collecting evidence, checking configurations across many machines. The people who automate that work get time back to do the interesting parts, and they get noticed. The ones who do it by hand stay busy and stay junior.

Getting the first job

In rough order of how well they work:

• InternshipsIf you are in school or within a year of finishing. Nothing else comes close.
• Government and contractor rolesUSAJobs is genuinely the best starting point in the US. Federal work hires people without experience, trains them, and the framework exposure transfers everywhere. It is also where I came up.
• Help desk or IT supportUnglamorous, and the single most reliable side entrance into security. You learn how real environments actually break.
• Volunteer workLocal small businesses, non-profits, a friend's company. Do it for the reference, not the money. A person who will vouch for you is worth more than another certification.

And when you write the resume, use everything that touches IT in any way. Nearly any technical task can be honestly framed in terms of what it has in common with security work. That is not embellishment — it is translation, and most entry-level candidates undersell themselves badly.

How long does it take

Anywhere from one year to four, depending on what you start with and how much time you can give it. I had a four-year degree in an unrelated field before I touched any of this.

Most people in this field are substantially self-taught. The degrees and certifications open doors; what gets you through them is having actually built something and being able to talk about what went wrong when you did.

Start now, start small, and keep the thing you built. It will be the most useful thing you can talk about in an interview.

This isn't theory

I currently have a junior developer working with me on one of my own products. He came in without a security background, and the arrangement is the one I'd recommend to anyone reading this: real work on a real thing, with someone reviewing it and explaining why the feedback is what it is.

That is the whole of it. There is no secret route into this field — there is somebody willing to let you do actual work, and somebody willing to tell you what you got wrong. If you can find the first, the second usually follows. I had both, and it is the only reason the accounting degree turned into a security career instead of a dead end.

So if you are further along than someone else, take the question. It costs an hour and it compounds in ways that are hard to predict.