Security engineering is the busiest hiring lane in remote tech

Scroll the newest roles in the directory and a pattern appears quickly. Among the engineering jobs added in the last few weeks, security titles keep turning up: incident response, infrastructure security, security assurance, DFIR, field engineering for security products. The companies are not boutique consultancies either. They are product companies with fully distributed teams.

If you have been treating security as a niche, the market disagrees.

Four different jobs wearing the same title

The most common mistake candidates make is applying to "security engineer" roles as if they were one role. In practice the listings split into four:

• Application security. Code review, threat modelling, fixing the classes of bug that keep recurring. You spend your day close to product engineers.
• Infrastructure and cloud security. Identity, network boundaries, Terraform and Kubernetes hardening, secrets management. Heavily operational.
• Detection and response. SIEM engineering, on-call, investigation, writing the runbooks. This work has a rhythm you either enjoy or do not.
• Assurance and governance. Audits, controls, evidence, customer questionnaires. Less glamorous, consistently in demand, and often the fastest route in for career changers.

Read the first three responsibilities in each listing and you can place the role in one of these buckets in under a minute. Apply accordingly, because the interview loops are completely different.

What employers screen for before the first call

Across the roles currently listed, the recurring requirements are less exotic than the titles suggest:

1. Evidence of hands-on work. A repository, a write-up, a CVE, a detection rule, a threat model. Something you built or found that someone can read.
2. Comfort with on-call. If the listing mentions incident response, expect a question about a real outage you worked through.
3. Breadth enough to talk to everyone. Security is a communication job as much as a technical one. Hiring managers listen for how you explain risk to people who do not share your vocabulary.
4. Cloud fluency. Nearly every listing expects at least one of AWS, GCP or Azure, and increasingly some Kubernetes.

A security hire who cannot explain a trade-off to a product manager is a security hire who will be ignored for two years.

How to read the seniority labels

Security titles inflate faster than most. One company's "staff" is another's "senior". Look at scope instead of the word: does the role own a domain end to end, or support a team that does? Do they mention mentoring, or only execution? Are you the first security hire, or the tenth? All three answers are visible in the listing if you look for headcount language and reporting lines.

Where the leverage is

If you are choosing what to learn next, the roles currently open skew toward cloud identity and detection engineering. Certifications help at the screening stage in larger enterprises and matter far less at product companies, where a working example beats a badge. The most reliable differentiator remains a short, specific write-up of something you did: what you saw, what you changed, what happened next.

Browse the engineering roles in the directory and filter by what the listing actually asks you to do, not by the title. The right role is usually the second one you read.