The underrated security fields you should actually be watching for the next 5 years

Everyone's staring at AI security like it's the only room in the building. Here's what's quietly happening in the rooms nobody's bothering to check.

Every "hot fields in security" listicle right now reads the same. AI security. Cloud security. AI security again, but with different buzzwords.

I'm not saying that's wrong — it's genuinely important, I write about it constantly. I'm saying it's crowding out a handful of fields that are about to matter enormously and currently have almost nobody in the room, which, if you're thinking about where to specialize for the next five years rather than the next five months, is exactly the kind of gap you want to know about before everyone else does.

Let's go through them properly, with the actual technical reasons each one's about to stop being optional.

1. Non-human identity security — the attack surface nobody's counting

Here's a number that should bother you more than it currently does: in a typical modern enterprise, non-human identities — service accounts, API keys, OAuth tokens, machine-to-machine credentials, CI/CD pipeline secrets, AI agent credentials — now outnumber human user identities by something like 10 to 1, and in some cloud-native environments the ratio is significantly higher.

Every conversation about identity security for the last two decades has been built around the human use case: passwords, MFA, SSO, conditional access policies tuned for a person sitting at a keyboard who can be challenged, who has a behavioral baseline, who notices when something feels off.

Machine identities have none of that. They don't notice anything. They don't have a "this feels weird" instinct. They get provisioned once, often with broader permissions than they'll ever use because someone was in a hurry, and then they sit there, frequently for years, frequently never rotated, frequently completely undocumented in terms of which human or system actually owns them. This is precisely the mechanism behind a meaningful and growing share of real breaches right now, a forgotten service account with stale, over-permissioned credentials sitting quietly in a system nobody's looked at since the engineer who set it up left the company eighteen months ago.

The field forming around this — non-human identity governance, sometimes called NHI security — is barely staffed right now relative to how large the problem already is.

Vendors are just starting to build real tooling for it. The skill set is a genuinely interesting hybrid: you need to understand identity and access management deeply, but also cloud architecture, secrets management, and increasingly, the specific behavior of AI agents that are now provisioning and using credentials autonomously, which is a brand new wrinkle nobody fully has their arms around yet. If you like identity work and want a field where the demand curve is about to go vertical while almost nobody's specialized in it yet, this is it.

2. Firmware and hardware-level security — the layer everyone assumes someone else is checking

Application security gets all the attention because it's visible, fast-moving, and full of CVEs with good marketing. Firmware security is none of those things, and it's also the layer sitting underneath every single one of your software defenses, which means a compromise there can render your entire software security stack functionally irrelevant, because you're now defending a house built on a foundation someone already tunneled underneath.

UEFI and BIOS-level implants, malicious firmware updates in IoT and networking hardware, supply-chain-implanted hardware backdoors — these aren't theoretical. They've shown up in real, documented incidents, and they're disproportionately hard to detect because most enterprise security tooling operates entirely above the firmware layer, looking at OS-level behavior, network traffic, and application logs, with essentially no visibility into whether the hardware itself has been tampered with before your operating system ever booted. A rootkit that persists at the firmware level survives a full OS reinstall. Think about how much of your incident response playbook assumes "wipe and reimage" actually fixes things, and then sit with the fact that it doesn't, for this specific category, at all.

The talent pool here is genuinely tiny, partly because it requires a different background than most security careers — closer to embedded systems and electrical engineering than to typical infosec — and partly because it's unglamorous, slow, deeply technical work that doesn't produce flashy conference talks as easily as a web app exploit chain does.

As more critical infrastructure, IoT, and edge computing devices proliferate, each one a tiny computer running firmware nobody's auditing, this gap is going to become impossible to ignore, and the people who already understand it now are going to be extremely difficult to replace.

3. Post-quantum cryptography migration — the deadline that's closer than it sounds

Everyone's heard the "quantum computers will break encryption" headline enough times that it's started to sound like background noise, the security equivalent of a car alarm nobody reacts to anymore. Here's why that reaction is a mistake: the actual threat isn't "wait until a sufficiently powerful quantum computer exists, then panic."

It's "harvest now, decrypt later" — adversaries, including well-resourced state actors, are already capturing and storing encrypted traffic today, specifically betting that quantum decryption capability arrives within a useful timeframe, at which point today's "secure" traffic becomes retroactively readable. If your data needs to stay confidential for more than a handful of years — health records, government data, long-term financial information, intellectual property — the clock already started, regardless of when the quantum computer that breaks it actually shows up.

NIST has finalized its first set of post-quantum cryptographic standards, which means the migration isn't a future problem to think about eventually — it's an active, present-tense engineering project that most organizations have barely begun, because cryptographic migration at enterprise scale is genuinely difficult, touching everything from TLS implementations to hardware security modules to embedded systems that can't easily be updated at all.

This creates a specific, narrow, high-demand specialty: people who understand both classical and post-quantum cryptography well enough to actually run a migration, not just cite the existence of the problem in a slide deck.

There are very few of these people relative to how many organizations are about to need one, and "very few people, growing mandatory demand" is exactly the shape of opportunity worth paying attention to early.

4. AI supply chain and model provenance security — securing the thing that trained the thing

Everyone's worried about prompt injection right now, reasonably. Almost nobody's worried yet about a quieter, structurally deeper problem: where did your model actually come from, what was it trained on, and has anything in that pipeline been tampered with.

Model weights get downloaded from public repositories the same way npm packages get pulled into a build — with roughly the same level of scrutiny, which is to say, often none. A maliciously fine-tuned model, a poisoned training dataset, or a tampered model file with an embedded backdoor that only activates on a specific trigger input is a category of supply chain attack that's structurally similar to the npm and PyPI problems the industry's been fighting for years, except the tooling, standards, and verification practices for model provenance are dramatically less mature, largely because the industry building these models is younger than the industry building software packages.

As more companies fine-tune and deploy models pulled from public hubs rather than training everything from scratch in-house — which is already the dominant pattern, not an edge case — verifying what you're actually running, where it came from, and whether anything was altered along the way is going to become as fundamental as software supply chain security is now, and right now there's barely a discipline here at all. The people who understand both ML pipelines and supply chain security thinking, together, are genuinely rare, and that rarity isn't going to last as a hiring advantage once everyone else figures out this gap exists too.

5. Privacy engineering — the discipline that's about to stop being legal's job alone

Privacy has historically been treated as a compliance function — a legal team's checklist, bolted onto engineering after the fact, mostly concerned with cookie banners and data retention policies. Privacy engineering is a genuinely different, technical discipline: building systems with privacy-preserving properties baked into the architecture itself — differential privacy, secure multi-party computation, properly implemented data minimization, federated learning approaches that avoid centralizing sensitive data in the first place. This isn't a checkbox. It's systems design, and it requires people who understand cryptography, distributed systems, and regulatory pressure simultaneously, which is a rare combination right now.

The forcing function here is regulatory and is accelerating, not slowing down — an expanding patchwork of global privacy law, increasing enforcement, and rising consumer expectation are converging on a point where "we'll handle privacy with a policy document" stops being a credible answer, particularly for any company training models on user data, which is most companies now. The technical depth this requires is closer to applied cryptography than to legal compliance, and almost nobody currently positions themselves at that specific intersection, which means almost nobody's competing for these roles yet either.

The actual pattern across all five of these

Every field on this list shares the same shape: a real, structurally growing problem, a regulatory or technical forcing function that guarantees it can't stay ignored indefinitely, and a current talent pool small enough that you could become genuinely excellent in any one of these within a few focused years and be ahead of almost everyone else who's still optimizing for the crowded, obvious fields everyone already knows are hot. The crowded fields aren't wrong to pursue. They're just crowded, and crowded fields compress your advantage exactly when you need it most.

The actual move, if you're early enough in your career to choose, isn't picking the field with the most job postings today. It's picking the field where the gap between "how big this problem already is" and "how many people currently understand it" is the widest, and building real depth there while almost nobody else is bothering to look.

Everyone's optimizing for the room everyone's already standing in. The interesting opportunity is almost always in the room nobody's checked yet — and right now, there are at least five of them with the door wide open.