Cybersecurity

How to get hired as a penetration tester in 2026-27

Updated 5 October 2026 · 30 min read · by SkillSculptor

The short answer

Penetration testing is not a licensed occupation in the United States, so hiring runs on evidence rather than credentials: one practical certification that gets you past the recruiter filter, plus one sanitised sample penetration test report that proves you can produce the deliverable clients actually pay for. OSCP is still the certification most often named in postings; Hack The Box CPTS and TCM Security's PNPT cost less and weight reporting more heavily. The report is the product, and not having one is the most common reason technically strong candidates stall, so write one against a target you are permitted to attack, in real deliverable format, with a scope and limitations table, a CVSS vector per finding, reproduction steps a client engineer could follow alone, cropped evidence and remediation written in business language. Hiring at a consultancy normally runs as a recruiter screen, a 45 to 60 minute technical screen on methodology and Active Directory or web attack chains, a timed hands-on practical that ends in a written finding, a report review, then a panel on scope, authorisation and client communication. Two markets gate formally instead: UK NCSC CHECK work needs CREST CPSA then CRT (CCT for Team Leader), SC clearance and a CHECK-accredited employer, and US federal or defence work needs a sponsored clearance plus a certification on the DoD 8140 qualification lists, which count for more than any offensive certification.

Is a licence required?No. No US state licenses penetration testing and there is no national register. Written authorisation takes its place: a signed scope and rules-of-engagement document from someone with authority to grant it is the only thing separating this job from an offence under the Computer Fraud and Abuse Act in the US, or the Computer Misuse Act 1990 in the UK. Hiring managers treat fluency with that paperwork as a credential, because their professional indemnity depends on it.
Certifications that pass screens (US private sector)OSCP (OffSec PEN-200) is still the most frequently named requirement and the default recruiter filter. HTB CPTS and TCM Security's PNPT cost less, weight the report more heavily, and are well regarded by practitioners but less recognised by non-technical screeners. PortSwigger's Burp Suite Certified Practitioner is the strongest single signal for web and API work. CRTP covers Active Directory, CRTO covers red team tradecraft, and OffSec's OSEP, OSWE and OSED cover evasion, white-box web and exploit development. CEH and CompTIA Security+ are paperwork rather than training, and they appear on the DoD 8140 qualification lists, which is why cleared contract postings keep asking for them.
The formal gate in the UK and regulated EU testingCREST CPSA (written) then CRT (practical) is the normal route to NCSC CHECK Team Member status; CCT Infrastructure or CCT Application is the Team Leader level. CHECK work also requires your employer to hold CHECK accreditation and you to hold SC clearance, so it gates at both ends and is a job eligibility test, not just a certificate. TIGER Scheme runs equivalents. Threat-intelligence-led testing under CBEST (Bank of England) or TIBER-EU runs through accredited providers with named qualified staff, which is why those roles are advertised by scheme name rather than by cert.
US clearanceYou cannot obtain a clearance yourself; an employer or agency sponsors it. A posting asking for an active Secret, Top Secret or TS/SCI with polygraph means active, and even an interim can take months. If you hold one, put the level and the date of your last investigation in your resume header. In the defence market it is frequently worth more than any offensive certification, and 'clearable' tells a recruiter nothing.
Realistic time to hireableFrom an existing IT, sysadmin, SOC or development job, plan on roughly 12 to 24 months of deliberate work: fundamentals, an Active Directory lab you built and broke, one practical certification, one published sample report, and some real research or paid bounty findings. From a standing start with no technical job, longer, and almost always with an IT or analyst role in between. Genuine junior penetration tester postings are rare; consultancy graduate and academy programmes are the one reliable zero-experience door and they run on an annual cycle.
The portfolio artefact that moves you mostOne sanitised sample penetration test report, roughly 12 to 25 pages, against a lab target you are permitted to attack, published as a PDF you can link from your resume. It is direct evidence of the thing employers sell and cannot assess cheaply in an interview: that you can turn access into a defensible document. A second certification does not substitute for it.
Typical hiring stagesRecruiter screen (certs, clearance, travel, right to work), a 45 to 60 minute live technical screen on methodology and attack chains, a timed hands-on practical lasting anywhere from four hours to a weekend that ends in a written finding, a report or writing review, then a panel covering scope, authorisation, ethics and client communication. Three to eight weeks end to end. Internal red teams at large technology companies substitute a software-style loop including a coding round; crowd platforms such as Cobalt Core and Synack Red Team vet you asynchronously with their own assessment.
Where to get pay numbers you can defendThere is no BLS occupation code for penetration tester. The closest authoritative US series is SOC 15-1212, Information Security Analysts, in the BLS Occupational Employment and Wage Statistics, which publishes 10th through 90th percentile figures nationally, by state and by metro. Then read live posted ranges in pay-transparency states (Colorado, California, Washington, New York, Illinois, Minnesota, Maryland, New Jersey and others), levels.fyi for internal security at large technology companies, and the GS-2210 tables plus locality for US federal roles. Ignore average-salary pages published by certification vendors and recruitment agencies; they are marketing with invisible methodology.

What a penetration tester actually does, and the adjacent titles people apply to by mistake

A penetration test is a time-boxed, authorised attempt to compromise a defined scope, followed by a written deliverable telling the client what you found, how you found it, what it would cost them, and how to fix it. In practice the second half is the product. The client is buying a document they can hand to an auditor, a board or an engineering team, with a named human's judgement attached. The breaking-in is the part you enjoy. The report is the part they paid for, and the part your performance review is built on.

Most penetration testing work in 2026 sits inside a consultancy. You are booked in one or two week blocks, you carry a utilisation target, you run two or three engagements a month, and you write up one engagement while the next scope is being agreed. Internal red teams at large companies run differently: longer operations, more detection evasion, a standing relationship with the defenders you are testing, and far less report volume. Crowd platforms sit in between. Knowing which of the three you are applying to changes how you present yourself, because the consultancy is hiring a billable, client-facing writer who can hack, and the internal red team is hiring an operator who will work alongside the blue team for years.

Title confusion costs people interviews before anyone looks at their skills. Read the posting's nouns rather than its title, because these are different jobs with different interviews:

What actually gates the job: certifications, schemes and clearances

In the US private sector nothing gates this legally. There is no licence, no board, no register. What gates it is a recruiter's filter and then a practice lead's confidence, and those are two audiences who respond to different evidence. The filter runs on certification acronyms, years-of-experience numbers and clearance status. The practice lead runs on your report, your methodology and the way you talk about scope. Candidates optimise hard for the first audience and then fail the second, which is how people end up with three certifications and no second-round interviews.

So the certification question is not 'which is best'. It is 'which audience am I trying to get past, and what will the technical panel want once I am through'. Pick by employer type rather than by forum opinion. A boutique that hires on published research cares very little about your acronyms. A large defence contractor's applicant tracking system cares about almost nothing else. Certification scheme details change, so confirm exam format, validity and renewal on the awarding body's own page before you write anything on a resume.

Three things are commonly mistaken for certifications but behave like licences, because without them you are not eligible for the work at all: UK CHECK status, a US security clearance, and company-level accreditation to deliver regulated testing.

How hiring actually works, stage by stage

Who screens you depends entirely on employer type. At a consultancy of any size, an internal recruiter runs the first pass against a list that is mostly certifications, years of engagement experience, clearance, willingness to travel and right to work. At a boutique, the founder or a principal reads your resume personally and will click your blog before they read your bullet points. At a large technology company's internal red team, the pipeline is the company's standard engineering pipeline with security rounds substituted in, which means a coding screen is likely. At a government contractor, clearance and 8140 paperwork dominate the first two stages and the technical bar is often assessed last.

The common shape at a consultancy, which is where most people get their first engagement job, is five or six stages across three to eight weeks. The stage that eliminates the most otherwise strong people is not the technical screen. It is the writing assessment, whether that is an explicit sample request, the report attached to a practical exercise, or a recruiter noticing that nothing in your application demonstrates you can write at all.

Two questions to ask the recruiter, because the answers change how you prepare. First, what the practical exercise is and whether reporting is included and weighted, because candidates routinely burn their whole time budget getting root and then submit three paragraphs. Second, whether AI assistants are permitted during the exercise. Firms have landed in different places on that and you should not guess.

The sample report: the one artefact that moves you past screens

If you do one thing from this article, do this. Produce a single sanitised penetration test report against a target you are permitted to attack, in real deliverable format, and link it from your resume as a PDF. It outweighs a second certification, any number of platform ranks, and a long skills section, because it is direct evidence of the output the employer sells and the thing they cannot assess cheaply any other way.

Read real deliverables before you write one. Several firms publish full reports: Radically Open Security publishes client-approved reports publicly, Cure53 and Trail of Bits publish engagement and audit reports for open source and funded work, and organisations like OSTIF and the Open Technology Fund publish the audits they commission. TCM Security and OffSec publish sample report templates. Read four real ones, then build your own template from what they have in common rather than from a blog post about report writing.

Targets you can legally use: retired Hack The Box machines where the platform permits write-ups, OffSec lab machines within their policy, intentionally vulnerable applications you host yourself (OWASP Juice Shop, DVWA, WebGoat), an Active Directory lab you built (GOAD and similar projects give you a realistic domain to break), Vulnhub images, your own home network and your own cloud account. A target you own is always safe. Do not write up a bug bounty finding unless the programme's disclosure policy allows publication, and never write up anything from paid work.

Length is not the point; completeness is. Twelve to twenty-five pages covering a small scope properly beats sixty pages of padding. One good chained finding with a clear business consequence beats fifteen informational notes. If you can produce two reports, make the second a different discipline from the first, usually one infrastructure and one web application, so the set shows range.

Sanitisation rules are absolute and they are also a hiring signal. Never name a client, never reuse a real finding from paid work, never include a real customer's data even redacted, and if you have ever signed an NDA, assume everything under it is off limits permanently. A candidate who shows a reviewer a real client finding has just told them exactly what they would do with the next employer's clients.

What the interviews test: technical rounds, and the authorisation round that quietly rejects people

The technical rounds are not a trivia quiz, though they contain trivia. What is being assessed is whether you have a methodology you actually follow, whether you can reason from an artefact in front of you, and whether you know the limits of your own knowledge. The highest-scoring behaviour is narration: 'I would check X next, because Y', and 'I do not know, here is how I would find out', said without flinching.

The most common opening is a walk-through: 'you have an external scope of forty public IPs and a two-week window, talk me through your week'. The second most common is an artefact prompt: here is some nmap output, a Burp request, a BloodHound path, or a snippet of source, what do you do with it. Prepare both as rehearsed-out-loud narratives rather than as reading. You need genuine depth in one specialisation, working competence in Active Directory and web, and honesty about the rest.

Then there is the round confident candidates lose. Everything in penetration testing rests on a piece of paper: a signed scope and rules-of-engagement document, granted by someone with authority to grant it, naming systems, times, techniques and contacts. Without it the same keystrokes are an offence under the Computer Fraud and Abuse Act in the US or the Computer Misuse Act 1990 in the UK. The US Department of Justice's charging policy from May 2022 directs prosecutors not to charge good-faith security research, which helps the profession and is emphatically not a permission slip for testing something you were not hired to test.

The case every hiring manager in this field knows is the Coalfire one: in September 2019 two testers on an authorised physical engagement were arrested in an Iowa courthouse after a jurisdictional mismatch between the state judicial branch that hired them and the county that owned the building. The charges were dropped in January 2020. The lesson the industry drew is not 'physical testing is risky'. It is that authorisation has to come from the party that actually controls the asset, that the paperwork has to be on your person, and that a named 24-hour escalation contact has to answer the phone. The scenario questions below have correct answers, and they are correct because they match what a firm's insurer, legal counsel and client contract require.

The resume: what lands, line by line, and what gets ignored

Two audiences read this document in sequence. A recruiter or an applicant tracking system looks for cert acronyms, clearance, engagement counts, sectors and location in about fifteen seconds. A practice lead then looks for whether you have run engagements, whether you have written the deliverable yourself, and whether your findings have consequences attached. Write for both without pretending the first audience does not exist.

The structural decision that matters most is where your evidence lives. If you have professional engagement experience, it carries the document and projects go at the end. If you do not, invert it: a Research and Projects section sits directly under your certifications, carrying the sample report, CVEs, bounty findings and labs, and your unrelated work history goes below in two lines each. Hiding a career change behind a chronological resume with nothing in it is the most common self-inflicted rejection.

One page with no engagement experience, two once you have it. US federal and contractor resumes run longer by convention and the posting will usually say so. Plain formatting, no columns, no graphics, no skill-level bar charts, no certification badge images. The parser will mangle them and the practice lead will read them as padding.

Pay, and the specialisations that move it

Be sceptical of every salary figure you read about this role, including the ones on certification vendors' blogs and recruitment agencies' landing pages. Those pages exist to sell a course or a placement and their methodology is usually invisible. There is also no BLS occupation code for penetration tester, which means every 'average penetration tester salary' statistic you see has been derived from self-reported data or scraped postings by someone with a commercial interest.

The defensible approach is to triangulate from sources that publish their method. Start with the BLS Occupational Employment and Wage Statistics for SOC 15-1212, Information Security Analysts, which gives percentile distributions nationally, by state and by metro. That code bundles defensive and offensive work, so treat it as the distribution your market sits inside rather than as a number for your title, and check it against live postings rather than assuming a premium. Consultancy compensation also has a different shape from internal security: often a lower base with utilisation or billable bonus on top, plus travel. Then read live posted ranges for your exact target title and level in pay-transparency jurisdictions, which is the most accurate free signal available because employers are legally obliged to publish them.

What moves the number is less about certifications than candidates expect and more about three things: specialisation scarcity, whether you can lead an engagement and own the client relationship rather than execute someone else's scope, and in the US defence market, clearance.

Getting in with no engagement experience: the routes that actually convert

Say the hard thing first. Genuine junior penetration tester postings are rare, entry level across the security field has been tight through the mid-2020s, and the gap between 'can root boxes on a platform' and 'can be put in front of a paying client' is wider than training providers imply. Almost nobody goes from no technical job to penetration testing directly. Almost everybody goes through something else first, and the people who get there fastest pick that something else deliberately.

The indirect routes work for a specific reason, not out of patience. You cannot competently test an Active Directory environment you have never administered, or a web application you have never shipped, or a cloud account you have never had to pay for. The testers who progress quickly are the ones whose previous job gave them the defender's or the builder's model of the thing they are now attacking, and that also interviews well: 'here is what my attack looks like from your SIEM' is a sentence a red team lead remembers.

If you want a concrete twelve to twenty-four month plan, the sequence in the last bullet below is the one with the highest conversion rate, and it is deliberately cheap. Nothing in it except one certification costs real money.

Working with AI in this role

What a penetration tester must know about AI in 2026-27

Start with the honest counterweight, because the hype in this field is loud and a practice lead will mark you down for repeating it. At the core, this job has changed less than the marketing suggests. The findings that land in the critical section of reports in 2026 are the same classes as five years ago: Active Directory misconfiguration chains, exposed and unpatched services, weak credential hygiene and password reuse, broken access control in web applications, server-side request forgery, and insecure direct object references. None of those has been automated away. Broken access control in particular cannot be found by a tool, because finding it requires knowing what a given user is supposed to be permitted to do, and that is business context no scanner has. Anyone telling you penetration testing is being replaced is selling a product.

Four things did change, and they are specific. First, the attack surface grew a new category: scoping documents now routinely include an LLM feature, a retrieval pipeline, or an agent with tool access and real credentials, and most testers are not fluent in it, which makes fluency a genuine differentiator right now. Second, the commodity end of the market is under real pressure, because a templated annual external scan with a generated report is exactly what breach-and-attack-simulation and autonomous scanning products are built to replace, so a firm whose offering is only that has a harder commercial story in 2026 than it had in 2021. Third, model-driven bug finding stopped being a demo: XBOW, an autonomous system, reached the top of HackerOne's US leaderboard in 2025, Google's Big Sleep project found a real memory-safety defect in SQLite before it shipped, and the DARPA AI Cyber Challenge finals at DEF CON in August 2025 had cyber reasoning systems finding and patching genuine defects in open source code. Those systems are strong at breadth, at pattern-shaped web vulnerability classes, and at fuzzing and triage where source is available. They are weak at multi-step business logic abuse, at chained identity attacks that require client-specific context, at judging what a finding is worth to this particular business, and at everything human about an engagement. Fourth, the deliverable workflow changed: where firms permit it, testers draft findings with model assistance and then edit, which raises the floor on report readability and moves the differentiator from 'can write' to 'can judge and prioritise'.

The client-data question is now asked in interviews, and it is a scoring question. Pasting a client's source code, scope document, or screenshots of their internal hosts into a third-party model is a confidentiality breach at most consultancies and a contractual one at some. Firms have landed in three places: a blanket prohibition, an approved enterprise tenant with data-retention guarantees and a documented list of permitted uses, or a self-hosted model. The answer that passes names the boundary without being prompted: what you will put in (your own notes, public advisory and CVE text, a snippet you have genuinely rewritten so it carries no client identifiers), what you will never put in (client names and identifiers, raw evidence, credentials, proprietary code), and that you follow the firm's policy over your own preference. Add that you verify every generated technical claim before it reaches a client document, because a hallucinated CVE number or a fabricated remediation reference in a deliverable is an unrecoverable credibility failure for the whole firm, not just for you.

Finally, do not confuse penetration testing an AI feature with AI red teaming as a safety discipline. Probing a model's propensity to produce harmful content, be jailbroken, or breach policy is usually a different job, in a different organisation, measured on different things. Security testing of an AI system is about a concrete security consequence: the injection that made an agent call a tool it should not have called, the poisoned document that caused a cross-tenant data read, the generated output rendered without encoding that became stored cross-site scripting. Interviewers can tell the difference in one question, and candidates who present a folder of jailbreak prompts as AI security experience get marked down for it.

Prompt injection, direct and indirect, treated as a security finding rather than a party trick

Indirect injection is the variant that produces real reportable findings. Content the model ingests on a user's behalf, a web page, a PDF, a calendar invite, a support ticket, a repository README, carries instructions, and the model acts on them with that user's privileges. There is still no reliable general fix, which is precisely why clients pay to have it found, and why the remediation conversation has to be about blast radius rather than about filtering.

Show it: Walk one chain end to end against something you built yourself: the injection source, the trust boundary it crossed, the tool the model was persuaded to invoke, and the concrete consequence, a record changed, data read across a boundary, an email sent. Then give the mitigation in architectural terms: human confirmation on state-changing tools, least-privilege credentials per tool, output encoding at the sink, structural separation of untrusted content from instructions, and a hard cap on what the agent can reach at all.

Agent and tool-calling abuse, including Model Context Protocol servers

Agentic deployments hand models credentials and side effects, and MCP made tool integration cheap enough that production systems now expose a whole stack of them, often assembled by people who did not review the security model. The documented failure modes are classic bugs in new clothing: over-broad OAuth scopes, a confused deputy where the agent acts with more authority than the requester had, tool descriptions that are themselves an injection vector, and no audit trail of which tool acted on whose behalf.

Show it: Enumerate an agent's tools and their scopes as an attack surface and present it as a privilege map rather than a list. Show one case where the agent's effective permissions exceeded the user's, name the primitive precisely (confused deputy, scope over-grant, tool poisoning), and write the remediation as a permission and architecture change rather than as a prompt change, because a prompt is not a control.

Retrieval and data-boundary testing

A retrieval pipeline is an access control problem wearing a machine learning hat. If the index does not carry and enforce the same authorisation as the source systems, one user's question returns another user's or another tenant's document, and that is a reportable data exposure under essentially every regime a client reports against. It is also the AI finding most likely to be rated critical, because it needs no exploit chain to explain.

Show it: Describe testing retrieval with two accounts at different privilege levels and demonstrating a cross-boundary read, plus a document-poisoning case where content you planted was retrieved and acted upon. Say what you checked at ingestion: whether source permissions are carried into the index, whether deletions and revocations propagate, what is retained in embeddings, and what is logged when a document is retrieved.

Insecure output handling, the unglamorous finding that is actually exploitable

Model output is untrusted input to whatever renders or executes it. Teams that would never trust a form field will interpolate generated text straight into HTML, a shell command, a SQL string or a template, which turns the model into a delivery mechanism for cross-site scripting, command injection and template injection. This class survives the client's own review more often than most, because nobody on the team thought of the model as a user.

Show it: Show one finding where you steered a model into emitting a payload that the surrounding application then rendered or executed, and write it up as the injection class it genuinely is, with the model named as the vector. That framing is what gets it fixed at the sink instead of patched with a prompt instruction that the next model update will ignore.

Reading the standards the client is being audited against

Scoping an AI assessment is partly a selling skill, and the firms winning that work cite frameworks the client already reports on. The OWASP Top 10 for Large Language Model Applications, now maintained under OWASP's GenAI Security Project, and OWASP's agentic security work give you shared vocabulary with the client's engineers. NIST's AI Risk Management Framework and its generative AI profile, ISO/IEC 42001, and the EU AI Act obligations phasing in across 2026 and 2027 are what the client's risk function is measured against.

Show it: Reference a specific framework in the methodology section of your sample report and map at least one finding to it. In interview, be able to say what an AI assessment scope document should contain, including which model versions, which tools, whether training or fine-tuning data is in scope, and what the rules of engagement say about rate limits and inference cost. This is where most candidates go blank, and it is the question a practice lead asks to find out whether you have done one.

Using assistants on the reading and writing half of the job, inside a stated boundary

The honest productivity gain is not exploitation, it is the surrounding work: a first draft of a finding from your own notes, an executive-language rewrite, a one-off parser, orientating in an unfamiliar codebase, deobfuscation, and compressing a long scoping pack. Firms ask about this directly because the confidentiality exposure is real and a careless tester is an insurable liability.

Show it: Name your boundary before you are pushed on it: client identifiers, raw evidence, credentials and proprietary code stay out; your own notes, public advisory text and genuinely rewritten snippets are acceptable; and the firm's tenancy and retention policy beats your personal habits. Then say that every generated technical claim gets verified against a primary source before it reaches a client document, and give an example of something you caught.

Knowing what the automated products actually do, because clients will ask you to justify your existence

Clients who have bought a breach-and-attack-simulation platform or an autonomous scanning product will ask why they still need a human engagement. 'Because tools miss things' is not an answer and reads as defensive. The usable answer is specific about coverage: these products are strong at known-signature breadth, repeatable regression and continuous coverage between engagements, and they do not model authorisation intent, do not chain across systems the way an operator does, and cannot weigh what a finding is worth to this business.

Show it: Have actually run one, or at minimum read its documentation and its own stated limitations, and be able to name a finding class it structurally cannot reach and explain why. Position yourself as the layer above continuous automation rather than in competition with it, because that is the commercial reality of how the work is now sold.

Detection-aware operating, now that the defenders got the same upgrade

Anomaly scoring, log summarisation and alert triage are increasingly model-assisted on the blue side, which changes what gets noticed and how quickly. On a red team engagement, 'would this be caught' is now a different calculation, and measuring it is a large part of what the client is paying for. Clients increasingly value the detection gap list alongside the vulnerability list, because parts of the vulnerability list they can now generate themselves.

Show it: Describe an engagement where you tracked what fired and what did not, mapped each action to MITRE ATT&CK technique identifiers, and delivered a detection gap table alongside the findings. That artefact is the shape of purple team work and it is the clearest way to show you understand the defender's side of the engagement.

Source-available review speed, with your own judgement still doing the deciding

More assessments now arrive with code attached, and model assistance genuinely makes a reviewer faster at orientating in an unfamiliar codebase, tracing a dangerous sink back to a reachable source, and noticing a route with no authorisation decorator. What it does not do is decide what is reachable in production or what the authorisation model was supposed to be, and that is the part you are paid for.

Show it: Describe a finding you reached by reading code rather than by probing a running system, and then say what you confirmed dynamically afterwards, because unverified code-reading findings get rejected by clients. Pair it with one example where the assistant was confidently wrong and say exactly what caught it.

Saying plainly where AI has not changed your job

Overclaiming is the fastest route to failing a technical interview with someone who does this work daily. The credibility move is exactness: the core finding classes, the Active Directory chains, the access control work, the authorisation judgement and the client relationship are unchanged, and here is the specific short list of what did change. A candidate who can draw that line reads as someone who has done the work rather than read the newsletter.

Show it: Answer the AI question in two halves. First, something you have actually tested in an AI system with a concrete security consequence. Second, what you think is overstated, with a reason. Then bring it back to a finding you found by hand that no tool would have reached, and say why it would not have.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

Mistakes that cost people this job

Collecting a third certification instead of producing one sample report.

Stop after the cert that clears your target employers' filter and spend the next three weekends writing a 12 to 25 page sanitised report against a lab target, published as a linkable PDF. It is the only artefact that proves the thing employers actually sell, and it is the gap hiring managers name when they explain why a technically strong application went nowhere.

Applying with no operating system, networking or Active Directory fundamentals, on the strength of platform boxes alone.

Guided boxes teach exploitation and hide enumeration and context. Build a small Active Directory domain yourself, join two workstations, configure group policy, break it and then fix it. You cannot credibly test an environment you have never had to run, and interviewers find this out in two questions.

Presenting a platform rank or streak as the evidence base: a TryHackMe percentile, a Hack The Box title.

Convert the hours into artefacts a hiring manager can evaluate: named Pro Labs completed, a published write-up that shows your reasoning, a sample report, a CVE, a paid bounty finding. Ranks measure time spent on a platform, which is not what anyone is buying.

Putting real client findings, client names or redacted client screenshots in a portfolio.

Never. Use a fictional client name against a lab target you own or are permitted to attack, and describe paid work only by shape ('a top-five US retail bank'). Showing a reviewer a real client finding tells them precisely what you would do with their clients, and it is a rejection at any competent firm.

Volunteering that you once tested something without authorisation, usually framed as initiative.

Do not. One sentence about poking your university portal, a previous employer, or a site that annoyed you ends the interview at most firms, because the interviewer's whole job in that round is predicting what you will do with privileged client access. If something genuine happened years ago and was resolved, think hard before raising it and never frame it as resourcefulness.

Treating the report as the chore after the fun part, and the written component of a take-home as optional.

Budget the practical exercise as half hacking and half writing from the start, and ask the recruiter explicitly how the written component is weighted. Candidates routinely get root and then submit three paragraphs, and lose to someone who found less and documented it properly.

Answering the out-of-scope host question with 'it was in the range, so I tested it'.

Stop, document, contact the named technical point of contact, and get written confirmation before touching it. Clients do not know what is in their own ranges and third-party assets live there. This question exists specifically to find out whether you will create legal exposure for the firm.

Sitting on a Domain Admin compromise so the report looks dramatic.

Report it the same day, then agree in writing whether to continue for coverage or pivot to a different objective. Hiring managers ask this exact scenario, and the self-aggrandising answer fails because in real engagements it is how firms lose accounts.

Chasing red team operator postings with no penetration testing engagement history.

Red team roles almost universally expect engagement experience first, so those applications are usually discarded at the recruiter stage. Target penetration tester, vulnerability management or application security roles at organisations that have an internal red team you could transfer into, and get CRTP or CRTO on the way.

Applying to US cleared postings assuming the clearance can be sorted out later, or claiming to be 'clearable'.

A posting asking for an active Secret or TS/SCI means active, and sponsorship takes months with no guarantee. If you have no clearance, target commercial consultancies and internal teams, and treat sponsorship as a multi-year plan rather than an application strategy. If you have one, put the level and investigation date in your header.

UK candidates ignoring CREST and CHECK because US-centric advice says OSCP is all that matters.

If your target employers are CHECK-accredited, CREST CPSA then CRT plus SC clearance is the actual eligibility gate for the work they sell, and CCT is what the Team Leader pay step is attached to. Ask in the first recruiter call which scheme the firm's work runs under and plan to it.

Rating everything critical, or quoting a CVSS base score with no environmental reasoning.

Give the vector string, then one sentence on why the contextual severity differs from the base score in this environment. Severity inflation is the fastest way to lose a client's trust and it is immediately visible in a report sample. Being able to argue a medium up to a critical, with the asset named, is the judgement the whole job rests on.

Preparing for the technical screen by reading rather than by talking.

Rehearse out loud and on a timer: a full external methodology walk-through, a full internal one, and three artefact prompts (nmap output, a Burp request, a BloodHound path). The round scores verbal structure and narration, and silence while you think reads as being stuck even when you are not.

Pitching a folder of jailbreak prompts as AI security experience.

Show one AI finding with a concrete security consequence: an indirect injection that made an agent invoke a tool it should not have, a retrieval boundary that returned another account's document, or generated output rendered without encoding that became stored cross-site scripting. Then say plainly which parts of the AI disruption story you think are overstated, and why.

Ignoring what the job is like day to day, then washing out of it.

Consultancy penetration testing comes with timesheets, utilisation targets, travel, scoping calls, client debriefs and a large amount of writing. People leave because of those things far more often than because the hacking was too hard. Decide you want that job, not just the exploitation, before you spend two years aiming at it.

Questions people ask

Do I need a degree to become a penetration tester?

No degree is required to work as a penetration tester, and there is no licence for penetration testing in the United States. Plenty of working testers came from IT support, system administration, the military or software development. A degree helps in two specific situations: consultancy graduate and academy programmes, which recruit on an annual cycle and often screen on education, and US federal roles in the GS-2210 series, where qualification standards can require a degree or specific coursework. Outside those two, a practical certification plus a sanitised sample report plus demonstrable fundamentals will get you further than a degree with none of those.

Which penetration testing certification should I get first?

Pick your first penetration testing certification by who will screen you, not by which is most respected. If your targets are US consultancies and enterprises with recruiter-led filtering, OSCP is still the acronym that opens the most doors. If you are self-funding and your targets are technically led, Hack The Box CPTS or TCM Security's PNPT give you far more reporting practice for a fraction of the price, and PNPT's live debrief rehearses the skill most candidates lack. For web and API testing specifically, work the free PortSwigger Web Security Academy end to end and take the Burp Suite Certified Practitioner exam. If you are weak on Active Directory, CRTP is the cheapest fast fix. If your target is UK CHECK work, the path is CREST CPSA then CRT regardless of what else you hold.

Is OSCP still worth it in 2026?

OSCP is still worth it in 2026 for passing screens, but not as a substitute for a sample report. It remains the certification most frequently listed in penetration tester postings and the most reliable way to get a recruiter to pass your resume to a practice lead. It does not prove you can run a client engagement, scope work, or write a deliverable someone will pay for, and interviewers no longer assume it does. Note that the exam is sold bundled with PEN-200 course access rather than on its own, so budget for the package. Treat OSCP as the key to the door and the report as what happens once you are inside.

How long does it realistically take to get hired as a penetration tester?

From an existing IT, system administration, SOC or software development job, getting hired as a penetration tester realistically takes roughly 12 to 24 months of deliberate work: fundamentals, an Active Directory lab you built and broke, one practical certification, one published sanitised report, and some real research or paid bounty findings. From a standing start with no technical job, longer, and almost always with an IT or analyst role in between. Anyone promising a career change into penetration testing in three months is selling a course.

Can I get a penetration testing job with no experience at all?

Getting a penetration testing job with no professional experience happens through three specific doors. Consultancy graduate and academy programmes recruit people with strong lab and CTF records and no work history, on a fixed annual cycle, so you have to apply at the right time of year. Crowd testing platforms such as Cobalt Core and Synack Red Team vet you with their own practical assessment and then pay per engagement, with no employer sponsorship needed. And internal transfers happen constantly, which is why getting hired into IT, vulnerability management or a SOC at a company that has an internal red team is faster than applying externally for junior tester roles that mostly do not exist. Linkable bug bounty findings on a named programme strengthen all three, because a real triage team disagreed with you and you handled it.

Do penetration testers need to know how to code?

Penetration testers need coding at a scripting level, and more than that for some specialisations. Expect to read and modify Python, write Bash and PowerShell, understand enough of a web application's source to spot a missing authorisation check, and be able to put together a one-off parser or a proof-of-concept request chain. Full software engineering ability is not required for network testing, but it is effectively required for exploit development, application security and tool building, and it is the single most useful thing to have if you are moving in from development.

Is it legal to practise penetration testing at home?

Practising penetration testing is legal on systems you own and on platforms that explicitly authorise it. Lab platforms, intentionally vulnerable applications you host yourself, your own network, your own cloud account, and bug bounty programmes within their published scope and rules are all legitimate. Everything else is not, including your employer's network without written permission, your university, and any site you happen to find interesting. In the US, unauthorised access is a Computer Fraud and Abuse Act matter and in the UK a Computer Misuse Act 1990 offence, and the US Department of Justice's 2022 policy of not charging good-faith research is not a permission slip for testing something you were not engaged to test.

What is the difference between a penetration tester and a red team operator?

A penetration tester works to a scope and is measured on coverage: find as much as possible in the agreed systems within the time box, and document it, with detection usually not the point. A red team operator works to an objective, such as reaching a specific data set or processing a fraudulent transaction, over weeks rather than days, using command and control infrastructure and deliberate evasion, and is measured partly on whether the defenders caught them. Red team roles almost always expect penetration testing experience first, which is why applying to them with none is the most commonly wasted application in this field.

Is AI reducing the number of penetration testing jobs?

AI is reshaping the penetration testing market rather than shrinking the profession, and the pressure is concentrated at the low end. Templated annual external scans with generated reports are exactly what automated breach-and-attack-simulation and autonomous scanning products are built to replace. Model-driven bug finding has also become genuinely capable at breadth and at source-available triage, as XBOW's HackerOne US leaderboard result in 2025, Google's Big Sleep findings in SQLite, and the DARPA AI Cyber Challenge finals in August 2025 all showed. What has not moved is the work that needs business context: broken access control, multi-step logic abuse, chained identity attacks in a specific client's environment, judging what a finding is worth, and signing a deliverable. New demand has appeared on the AI surface itself, in prompt injection, agent and tool abuse, and retrieval data boundaries.

What do penetration testers get paid, and where can I check without being misled?

There is no BLS occupation code for penetration tester, so every 'average penetration tester salary' page has been derived by someone with a commercial interest in the number. Use the BLS Occupational Employment and Wage Statistics for SOC 15-1212, Information Security Analysts, for percentile distributions by state and metro, treating it as the distribution your market sits inside rather than as a figure for your exact title. Then read live posted ranges for your target title in pay-transparency states such as Colorado, California, Washington, New York and Illinois, which is the most accurate free signal available because employers are legally required to publish them. For large technology companies use levels.fyi; for US federal roles the GS-2210 tables plus locality and the DoD Cyber Excepted Service bands; for UK CHECK work the day rates published on public sector frameworks. Clearance in the US defence market and the CHECK Team Leader step in the UK are the two clearest single pay jumps.

Put this on a resume in about a minute

Paste your history once and point it at the Penetration Tester posting you are looking at. No account, no card.

Build my resume free More roles

Related roles