The bottleneck in a cybersecurity career isn't certs and it isn't labs. It's operational time on systems other people depend on. Qualifications and labs can show learning and practical reasoning, but they do not establish responsibility for a live service. The next step is to connect that preparation to appropriately supervised work.
Who this is for
- You've passed Security+, maybe CySA+, maybe even started CISSP self-study, and the security roles you applied to went silent.
- You've done HackTheBox, TryHackMe, BTL1 and a couple of CTFs, and you're starting to suspect lab time isn't converting the way the content promised.
- You're already in a security-adjacent role and wondering why the jump to a senior title keeps slipping by another six months.
The thing the industry won't say plainly
Security work is judgment work. The judgment is "is this normal, and if it isn't, does it matter, and if it does, what do I do about it, and what does the business lose if I get the answer wrong". You can practise parts of that judgment in labs, but their consequences and uncertainty differ. In many exercises you know there is a flag. You know the flag is somewhere reachable. You know the environment was built to be solved. Real systems are unbounded, weren't built to be solved, and the cost of being wrong is somebody's revenue or somebody's data.
That judgment develops through repeated decisions and feedback, including responsibility for something that other people depended on, and where being wrong cost something. It almost doesn't matter what the something was. Support. Sysadmin. Junior SOC. Network operations. A small dev team. The shape of the experience matters more than the title.
This is the bottleneck. Not the cert. Not the lab hours. The operational time on real systems with real consequences. Everything else in the standard advice (more certs, more labs, more YouTube) is downstream of this and won't fix it.
Why the standard advice keeps missing it
Because the standard advice is written by people who have a commercial interest in solving the wrong problem.
Cert vendors sell certs. Lab platforms sell lab hours. Bootcamps sell bootcamps. Content creators sell ad views. None of them sell "go work helpdesk for two years first", because none of them can monetise that. So the bottleneck gets renamed as a knowledge problem (more study), a skills problem (more labs), or a portfolio problem (more GitHub). Those can address genuine gaps, but none automatically supplies operational responsibility. A portfolio helps make existing work visible; it cannot manufacture experience.
Hiring managers know this. They write job specs that say "three years experience" and they mean three years of being responsible for production systems, not three years of evening study. Whether that requirement is proportionate depends on the role. Entry-level jobs need room for supervision and development; demanding prior responsibility for every junior vacancy can close the pipeline employers rely on.
What "operational time" actually means
Specific list, because the phrase gets used loosely.
- You've been on call for something. Even something small. You know what 3am feels like when the pager goes and you're the only person who can fix it.
- You've broken production. Not a lab. Production. You've felt the stomach drop, the cold call to your manager, the slow rebuild of trust over the following week.
- You've sat in a change advisory board, or its scrappier equivalent, and watched a senior engineer explain why your beautifully designed change isn't going in this Tuesday.
- You've been the person who got the angry user email when the patching window ran long.
- You've documented something that mattered, six months later watched a new colleague rely on that document, and quietly realised what good documentation actually costs.
Those examples help explain operational responsibility in a way a credential alone cannot. Their value still depends on the role and employer; we cannot rank them above every certification for every vacancy. Keep supervised work and lab evidence clearly labelled.
What people get wrong
The most common move is to substitute volume for depth. Six certs, four lab platforms, two bootcamps, a Discord, a stack of bookmarks, and no operational hours. Each piece feels like progress because each piece costs effort. None of it lifts the ceiling, because the ceiling isn't made of knowledge, it's made of trust. Employers trust people who've already been trusted by an employer to run something. There's no certification for that.
The second mistake is treating "security" as a single thing. SOC, detection engineering, incident response, vulnerability management, application security, cloud security, GRC, identity, architecture. Each of those has its own feeder roles, its own operational prerequisites, and its own bottleneck. Stacking generalist security content doesn't move you along any specific one of them.
The third mistake is describing lab work as production experience. A well-recorded lab can show diagnostic reasoning, test discipline and an understanding of limits. Those are useful things for an entry-level applicant to discuss. Keep the setting explicit and identify which responsibilities still need supervised experience.
The realistic route through the bottleneck
Get into a role with operational responsibility, even if it doesn't say security on it. Help desk at an MSP. Sysadmin at a small or medium employer. Junior network engineer somewhere with a functioning team. Junior SOC analyst at an MSSP. Anything that gives you systems to be responsible for.
Build those instincts through supervised practice and feedback. Volunteer for the unglamorous work. Get on the change board. Write the documentation. Join an appropriately supported on-call rotation when ready. Practise recovery in approved exercises; do not create production failures to build a portfolio.
Then move into the specific security flavour you want. By that point the cert that previously did nothing will start doing something, because it's no longer the entire story.
When this is wrong
Three real exceptions. You're transferring from a closely adjacent role that already produced the operational time (software engineering, sysadmin, network engineering). You're entering via a formal graduate scheme that includes the operational time as part of the programme. Or you have a referral into an apprenticeship at an employer that builds the time in.
Outside those, the bottleneck is real, the bottleneck is what it is, and the fastest route through it is to stop trying to go around it.
The 2026 evidence
Since I wrote this, the government's annual cyber security skills research has said the same thing in its own words. Employers and recruiters interviewed for the 2026 report described entry-level cyber as saturated, and some said entry-level roles increasingly required previous IT experience, including helpdesk experience. The same employers raised the pipeline problem directly: if the junior roles disappear, where do the future senior people come from?
I've written up the full findings in the UK cybersecurity job market in 2026. The short version: the bottleneck isn't a theory. It's now measured, dated and published.
Make the evidence visible
Capture a specific problem, your own contribution, the checks and the limits. Keep permitted supporting material and explain what you would do next. The first-role My Waymark example shows how lab and volunteering work can become a useful dossier and interview discussion, while keeping the need for supervised operational experience clear.
Where this connects on TechWaymark
The pathways page covers the realistic feeder routes into the different security specialisms. The certifications section says what each security cert actually signals once you've crossed the operational threshold, and which ones don't help until you have. For the cert-stacking version of this trap, read when cert stacking becomes the trap.