Security Hiring's DEI Collision: When 'We Need a Specialist' Becomes Code for 'Diversity Can Wait'

security_sam · February 13, 2026, 3:24am

The Tension Nobody Wants to Name

I need to talk about something uncomfortable that I see playing out across security hiring. And I say this as someone who cares deeply about both security excellence and diverse representation.

Here is the pattern: a company needs to hire a security engineer. The hiring manager writes a job description requiring 5+ years of experience in cloud security, specific certifications (OSCP, CISSP), expertise in threat modeling, incident response experience, and proficiency in at least two programming languages. The candidate pool that meets all these criteria is overwhelmingly male, overwhelmingly white or Asian, and overwhelmingly from a narrow set of educational backgrounds.

When someone raises the diversity concern, the response is: “We need a specialist. We cannot lower the bar.”

And that response sounds reasonable until you examine what is actually happening.

How “Specialist Requirements” Filter Out Diversity

Let me break down the mechanics:

1. Certification barriers. OSCP costs $1,600+ and requires weeks of dedicated study time. CISSP requires five years of professional experience and a $749 exam fee. These are not measures of capability — they are measures of access. They disproportionately filter out career changers, people from lower-income backgrounds, and professionals from emerging markets where these certifications are less common.

I did not have an OSCP when I started in security. I broke into the field through bug bounties — finding real vulnerabilities in real systems. My practical skills exceeded many OSCP holders I have met. But a certification-gated hiring process would have excluded me entirely.

2. Years-of-experience inflation. Many security job descriptions require 5-7 years of experience for mid-level roles. But cybersecurity as a defined career path is relatively young. The people with 7+ years of security experience entered the field when it was even less diverse than it is now. By requiring extensive experience, you are selecting from the least diverse talent generation.

3. “Culture fit” in security teams. Security teams often have strong internal cultures — hacker ethos, CTF competition backgrounds, specific communication styles. When hiring managers evaluate “culture fit,” they are often unconsciously selecting for people who match the existing team’s demographics and background.

4. The “tiered hiring” problem. Some companies have adopted tiered hiring approaches where specialized security and AI roles are exempt from broader diversity and inclusion efforts. The logic is: “We apply inclusive hiring practices to our general engineering roles, but security is different — we just need the best person.” This creates a two-tier system where the most high-status, highest-paying technical roles have the least diversity.

The Security Talent Shortage Is a Diversity Opportunity

Here is what frustrates me: the cybersecurity industry has roughly 3.5 million unfilled positions globally. We are facing a massive talent shortage. And our response is to narrow our hiring criteria rather than broaden them?

If there are not enough people with 5+ years of cloud security experience and an OSCP to fill available positions, the rational response is to develop talent, not to leave positions unfilled while waiting for unicorn candidates.

What Actually Works

From my experience building security capacity in Lagos and working with teams at Stripe and CrowdStrike:

1. Skills-based hiring over credential-based hiring. Give candidates a practical security assessment — a CTF challenge, a code review exercise, a threat modeling scenario. Evaluate what they can do, not what certificates they hold.

2. Invest in grow-your-own programs. Take strong engineers from other disciplines — backend, QA, DevOps — and train them in security. These career transitioners often bring domain knowledge that pure security specialists lack, making them more effective at securing the systems they already understand.

3. Recruit from non-traditional markets. The bug bounty community is remarkably diverse — researchers from Nigeria, India, Brazil, Indonesia are regularly finding critical vulnerabilities in Fortune 500 companies. These are world-class security minds who would never pass a traditional credential screen.

4. Separate “nice to have” from “must have.” Most security job descriptions list 15-20 requirements. In reality, 3-4 of those are actually essential for the role. Be honest about which ones matter and which ones are filtering for comfort rather than capability.

The Larger Point

When we say “diversity can wait because we need specialists,” what we are actually saying is “we have defined specialist in a way that excludes diverse candidates, and we prefer to maintain that definition rather than question it.”

That is not a security decision. It is a DEI decision disguised as a security decision. And in an industry with millions of unfilled roles, it is a bad business decision too.

cto_michelle · February 13, 2026, 3:26am

Sam, this is one of the most important posts I have read on this forum. You are naming something that most security leaders will not say out loud.

The Tiered Hiring Problem Is Real — And I Have Been Part of It

I need to be honest. At my company, we have had exactly the tiered approach you describe. Our general engineering hiring process includes structured interviews, diverse panels, blind resume reviews, and explicit diversity goals. Our security hiring process? “Find the best person.” Which in practice means: rely on referrals from existing team members, prioritize certifications, and hire from the same three companies everyone else recruits from.

The result? My engineering organization is 34% women and 28% underrepresented minorities. My security team is 11% women and 15% underrepresented minorities. Same company, same values statement, radically different outcomes.

When I saw those numbers side by side for the first time, I was embarrassed. I had been telling myself the story you described: “Security is specialized. The talent pool is what it is.” But the talent pool is what we made it through our hiring criteria.

What I Changed

Six months ago, I applied the same rigor to security hiring that we use for general engineering:

1. We rewrote every security job description. I brought in the security team leads and made them justify every requirement. “Why do you need OSCP for this role?” The honest answer was often “because that is what we have always required.” We cut requirements that were not genuinely predictive of job performance.

2. We introduced practical assessments. Instead of screening for certifications, we built a 4-hour take-home security assessment — reviewing a codebase for vulnerabilities, writing a threat model for a described architecture, and proposing a security roadmap. This tests actual security thinking, not credential accumulation.

3. We created a security apprenticeship track. Two positions per year, specifically designed for engineers transitioning from other disciplines. They work alongside senior security engineers for 6 months with structured mentorship and evaluation checkpoints.

4. We engaged with non-traditional pipelines. We started recruiting from bug bounty platforms, security-focused bootcamps, and African and Southeast Asian security communities. Sam, I know you have been involved in building the Lagos security community — that is exactly the kind of pipeline we need to be tapping.

Early Results

It has only been six months, so I want to be cautious about declaring victory. But our last two security hires were a career-changing QA engineer (Latina, 6 years of QA experience, zero certifications) and a bug bounty researcher from India (self-taught, no degree, extraordinary practical skills). Both are performing at or above the level of their certificated peers.

The “specialist” barrier was never about capability. It was about familiarity and comfort.

eng_director_luis · February 13, 2026, 3:26am

Sam, your point about certification barriers resonates hard. I see the exact same pattern in financial services, where compliance certifications create similar gatekeeping dynamics.

Building Security Pipeline From Non-Traditional Sources

In my organization, we have started approaching security pipeline building the same way we approach engineering pipeline building — by going upstream and investing in development rather than competing for a shrinking pool of credentialed candidates.

Our Community College Security Track. Through our Texas community college partnerships (which I mentioned in another thread), we added a cybersecurity concentration last year. The curriculum was co-designed with our security team to focus on practical skills: network analysis, secure coding practices, incident response procedures, and hands-on lab work with actual security tools.

The first cohort of 18 students is 56% women and 67% from underrepresented backgrounds. Not because we set quotas — because community colleges serve different demographics than four-year universities, and practical skills-based curricula attract different learners than theory-heavy academic programs.

Internal Security Rotation. We offer a 3-month security rotation for any engineer in the company. They embed with the security team, work on real security projects, and get exposure to the discipline. Three of our last five security hires came from this rotation. All three brought deep domain knowledge of the systems they had been building, which made them more effective security engineers faster than external hires.

The Credential Question in Financial Services

Sam, you mentioned OSCP and CISSP. In financial services, we have additional layers: CISM, CRISC, SOC 2 auditor certifications, PCI-DSS expertise. The credential stack can get absurd:

“Required: CISSP, CISM, cloud security certification, 7+ years experience, familiarity with SOX, PCI-DSS, GDPR, and CCPA compliance frameworks”

That job description eliminates roughly 97% of the global workforce. And the 3% who qualify are disproportionately from privileged backgrounds because acquiring those credentials requires time, money, and access.

What I tell my hiring managers: if your job description eliminates 97% of applicants, you do not have a talent shortage. You have a requirements problem.

We now differentiate between credentials we will hire for and credentials we will train for. If someone can pass our practical assessment and demonstrate security thinking, we will pay for their CISSP exam and give them study time. That one change increased our diverse candidate pool by 40%.

The talent is out there. We just need to stop building walls and start building doors.

data_rachel · February 13, 2026, 3:26am

Sam, I want to bring some data to this conversation because the bias embedded in “specialist” requirements is measurable and significant.

Quantifying the Credential Filter

I ran an analysis last year on publicly posted security job descriptions (n=2,400, scraped from major job boards). Here is what I found:

Average number of “required” qualifications per security posting: 14.3
Average number of qualifications held by the eventual hire: 6.8

That means companies are listing roughly twice as many requirements as they actually need. This is not unique to security, but the gap is larger in security than in general engineering (where the ratio is about 1.5x).

Now here is the diversity-relevant finding: each additional “required” certification reduces the percentage of female applicants by approximately 4% and underrepresented minority applicants by approximately 3%. A posting requiring one certification gets roughly 28% female applicants. A posting requiring four certifications gets roughly 12%.

The requirements are literally functioning as a demographic filter.

The “Specialist” Framing Creates Anchoring Bias

There is a well-documented cognitive bias at play here. When a role is framed as requiring a “specialist,” evaluators unconsciously apply stricter criteria and are less willing to consider non-traditional backgrounds. The same candidate evaluated for a “security engineer” role receives higher scores than when evaluated for a “security specialist” role — even when the job responsibilities are identical.

I tested this with a panel of 40 hiring managers. Same resume, same job responsibilities, different title framing:

“Security Engineer” framing: 62% of managers said “worth interviewing”
“Security Specialist” framing: 41% of managers said “worth interviewing”
The candidate was a career changer with strong practical skills and no traditional certifications

The word “specialist” activated a different mental model of who belongs in the role.

What Organizations Should Measure

If you want to know whether your security hiring process has a diversity problem, track these metrics:

Applicant-to-interview conversion rate by demographic — if women apply but do not get interviews at the same rate as men, your screening criteria are filtering them out
Requirement fulfillment rate — what percentage of “required” qualifications do your actual hires possess? If it is less than 70%, your requirements are aspirational, not actual, and they are doing more harm than good
Source diversity — where are your candidates coming from? If 80% come from employee referrals and your team is homogeneous, your pipeline will reproduce homogeneity
Time-to-productivity by hiring path — do certification-holders actually ramp faster than non-traditional hires? In my analysis of three companies, the difference was statistically insignificant after 6 months

Sam, your call for skills-based hiring over credential-based hiring is not just ethically sound — it is empirically supported. The data consistently shows that practical assessments are better predictors of job performance than certifications, and they produce significantly more diverse candidate pools.