"Security engineer" covers four very different jobs — product security, detection and response, infrastructure security, and governance — and every one of them has a different stack, pay range, and remote story. Treat the title as the start of the question, not the answer.
Four roles live under one title
The strongest thing you can do reading a security listing is identify which of these four it actually is within the first paragraph.
Product / application security engineer. Reviewing code and architecture for security weaknesses, writing threat models, running secure development programmes, handling vulnerability reports. Day to day: code review, SAST/DAST tuning, architecture review meetings, writing guidance for product teams. Often embedded with engineering teams. This is the role that overlaps most with software engineering and remote-scales well.
Detection and response / SOC engineer. Building and running the systems that catch attackers — SIEM tuning, detection rule authoring, incident response, threat hunting. Day to day: Splunk / Panther / Elastic / Datadog queries, writing detections as code, chasing alerts, running post-mortems. Usually on some on-call rotation. Remote-compatible when the tooling is properly cloud-native.
Infrastructure / cloud security engineer. Hardening the infrastructure itself — cloud configuration, network segmentation, IAM, secrets management, CI/CD security, Kubernetes security. Day to day: AWS/GCP/Azure security tooling, Terraform reviews, IaC policy, service mesh, zero-trust architecture. Heavy overlap with platform engineering and SRE.
GRC / compliance engineer. Policy, audit, SOC 2 and ISO 27001 programmes, vendor security reviews, privacy engineering, risk registers. Day to day: evidence collection, auditor meetings, policy writing, security questionnaires. Less hands-on code, more cross-functional. Nearly always remote-friendly, sometimes lower-paid.
Listings that don't tell you which of these they are — or that pack two of them into one role at a single seat — are usually an under-funded security team trying to hire a unicorn.
What remote security work actually looks like
Remote security engineering is among the more remote-native disciplines in tech — most tooling is cloud-native, most work is async-friendly, and the biggest employers in security have been distributed for years. GitLab, Cloudflare, HashiCorp, 1Password, Datadog, Snyk, Wiz, and the major cloud providers all run substantial remote security teams.
The practical differences from other engineering disciplines: an on-call rotation is common in detection and response; incident response work is bursty and high-intensity when it happens; some roles (particularly at regulated customers' vendors) involve travel for audits or customer meetings. Application security and GRC roles are the most async-friendly end of the discipline.
What the stack and certs actually look like
The honest summary: senior hiring managers weight experience over certifications. Certifications that carry weight when present: OSCP (hands-on offensive), CISSP (for senior roles at regulated customers), AWS/GCP/Azure security specialty certs (for cloud security roles), GIAC (GCIH, GCIA) for detection work. CEH, Security+, and CISM are common but weighted lightly.
Core technical skills across all four roles: strong Linux fundamentals, at least one scripting language (Python is the default, Go is increasingly common), cloud IAM at depth, and the ability to read and reason about code. Role-specific: AppSec engineers need to review code in whatever languages the company ships in (often a mix of TypeScript, Python, Go, and sometimes more); detection engineers need strong query skills and a working mental model of attacker behaviour (MITRE ATT&CK fluency is table stakes); infrastructure engineers need deep cloud and Kubernetes knowledge.
Five things worth checking before you apply
Which of the four flavours is this? AppSec, detection, infra, or GRC — each has a different stack and pay curve. If the JD smears across multiple, treat it as either a very senior role or an under-specified one.
What's the team size and structure? A two-person security team at a 500-person company is very different from a 30-person security team at the same scale. Smaller teams mean more breadth (good for learning, exhausting when incidents land). Larger teams mean more depth and actual coverage of your specialty.
Is security embedded with engineering or siloed? Healthy modern security orgs are embedded — AppSec engineers sit with product teams, detection teams work closely with platform and SRE. Siloed security organisations are slower, more friction-heavy, and often less effective.
What's the on-call story? Detection and response roles have meaningful on-call. AppSec and GRC usually don't. Infrastructure security varies. Always ask about paging frequency and how escalation works.
How do they measure success? Good security teams measure things that matter — mean time to detect, mean time to patch, percentage of critical findings fixed, clean audit outcomes. Teams that measure "number of tickets closed" or "vulnerabilities found" in isolation are either new or under-led.
Pay and level expectations
Senior security engineers are among the best-compensated ICs in tech, driven by a persistent shortage of experienced practitioners. US mid-level typically runs $150–200K base; senior $200–280K; staff $280–380K; principal higher. AppSec at AI-first and fintech companies trends highest. Detection engineering at large SaaS trends next. GRC work pays meaningfully less than the other three at equivalent titles but also has lower barriers to entry and better work-life balance.
European remote roles typically run 40–55% of US base for equivalent levels. Regulated industries in Europe — banking, insurance, healthcare — close the gap partly.
What the hiring process looks like
Security interviews vary sharply by flavour. For AppSec, expect a code review exercise — here's a small service, find the vulnerabilities — followed by an architecture/threat-modelling conversation. For detection, expect a write-a-detection exercise and a discussion of an incident you've worked. For infrastructure, expect a cloud security system design — "design a zero-trust architecture for X" or "review this Terraform for issues". For GRC, expect a policy-writing exercise and behavioural depth.
Across all four, background checks are common (often more thorough than in other engineering disciplines), reference checks are universal, and take-homes are normal.
Red flags and green flags
Red flags — step carefully:
- One job listing covering AppSec + detection + infra + GRC. This is a team that hasn't scaled and will burn you out.
- Certifications listed as rigid requirements at senior levels where experience should dominate.
- "Security is everyone's responsibility" as the only framing — usually code for "we don't actually resource security".
- No mention of tooling or current stack — suggests the programme is immature.
Green flags — healthy team:
- Clear role flavour and clear team size.
- Named tools and platforms with rationale ("we use Panther for detection because our logs are in S3").
- Embedded model with product or platform teams, not siloed.
- Incident retros shared internally, post-mortem culture mentioned.
- Security engineers write code, not just tickets.
Gateway to current listings
RemNavi doesn't post jobs. We pull them in from public sources and link straight through to the employer's own listing, so you always apply at the source.
Frequently asked questions
Security engineer vs. cybersecurity engineer — is there a real difference? At most companies, no. Larger and more security-mature organisations tend to use "security engineer" and reserve "cybersecurity" for customer-facing or policy-facing roles. Older enterprises and government-adjacent employers use "cybersecurity" more frequently. The work is the same; read the scope.
Do I need OSCP or CISSP to get hired remotely? No. OSCP signals hands-on offensive skills and is genuinely useful for red team / offensive security roles. CISSP is common at senior levels at regulated-industry vendors. Neither is a blanket requirement for remote security engineering roles. Experience, shipped security work, and open-source contribution are more influential.
How much on-call should I expect? For AppSec and GRC, usually none or very light. For detection and response, expect a meaningful rotation — typically week-on / week-off or similar, with paging frequency depending on the team's noise discipline. For infrastructure security, varies by company; often light. Always ask.
Can I move into security engineering from software engineering? Yes, and AppSec is the most natural route. Software engineers with security interest, a strong code-review instinct, and a few shipped security projects or CVEs are in demand. Detection work is harder to transition into without prior incident response or SOC experience. Infrastructure security transitions well from SRE and platform work.
RemNavi pulls listings from company career pages and a handful of remote job boards, then sends you straight to the employer to apply. We don't host the listings ourselves, and we don't stand between you and the hiring team.
Related resources
- Remote Cybersecurity Engineer Jobs — Overlapping role with broader policy scope
- Remote SRE Engineer Jobs — Reliability work that intersects security
- Remote DevOps Engineer Jobs — CI/CD security and infrastructure overlap
- Remote Platform Engineer Jobs — Platform security architecture
- Remote Backend Developer Jobs — Foundation for application security work