Remote product security engineers secure the applications that companies ship to customers — identifying vulnerabilities before they reach production, embedding security practices into the software development lifecycle, and building the tools and processes that allow engineering teams to write more secure code by default without needing to be security experts. The role is the application security layer of a modern security programme.
What they do
Product security engineers conduct application security reviews — threat modelling new features, reviewing pull requests for security issues, and running secure code reviews against OWASP Top 10 and product-specific risk patterns. They perform and triage vulnerability assessments — running SAST (static application security testing) tools (Semgrep, CodeQL, Checkmarx), DAST (dynamic application security testing), and dependency scanning — and work with engineering teams to remediate findings. They design and run bug bounty programmes, triage researcher submissions, and manage the responsible disclosure process for externally-reported vulnerabilities. They build security automation into CI/CD pipelines (security gates, automated scanning, policy-as-code) and develop security training and guidelines that help engineers understand and avoid the vulnerability classes most relevant to the company's stack and threat model.
Required skills
Strong software engineering background — the ability to read and understand code across multiple languages, write security tooling, and think like an attacker about how application code can be exploited — is the foundational requirement. Deep knowledge of web application security vulnerabilities (OWASP Top 10: injection, broken authentication, XSS, CSRF, IDOR, XXE, security misconfigurations) and the code patterns that produce them is required. Experience with security testing tools (Burp Suite, SAST/DAST tools, dependency scanners) and proficiency in manual penetration testing for web applications and APIs. Understanding of secure design principles — least privilege, defence in depth, zero trust, input validation, and secure defaults — for advising product teams on security architecture.
Nice-to-have skills
Experience with mobile application security (iOS and Android) for companies with significant mobile products. Background with cloud-native application security — container scanning, Kubernetes pod security, serverless security, and the OWASP Cloud Top 10 — is required at companies with cloud-native architectures. CEH, OSCP, or CISSP certifications signal security depth. Experience running a bug bounty programme on platforms (HackerOne, Bugcrowd) — including triage, deduplication, severity rating, and researcher relationship management — is valued at companies with mature external security programmes.
Remote work considerations
Product security engineering is highly compatible with remote work — code review, vulnerability assessment, tool development, and security training are all async activities. Bug bounty triage and researcher communication are naturally async. The collaborative dimension — embedding security review into the software development lifecycle without slowing it down — requires strong async communication habits: well-documented security guidelines, security-aware PR review templates, and self-service security resources that engineering teams can consult without waiting for a security engineer to be available. Remote product security engineers often develop expertise in async developer education and scalable security process design.
Salary
Remote product security engineers earn $140,000–$210,000 USD at mid-to-senior level in the US market, with staff and principal product security engineers at major technology companies reaching $240,000–$320,000+. European remote salaries range €85,000–€150,000. Consumer technology companies handling sensitive user data, fintech companies (high-value targets with significant financial fraud risk), healthcare companies with HIPAA obligations, and defence/government contractors with stringent security requirements pay at the upper end. Product security expertise commands meaningful premiums over general security roles due to the combined software engineering and security depth required.
Career progression
Software engineers who develop security expertise, penetration testers who develop secure code review skills, and information security analysts who learn software development move into product security engineering. From engineer, the path runs to senior product security engineer, staff security engineer, and principal security engineer. Technical leadership paths lead to head of product security, VP of Security, or CISO at product-first companies. Some product security engineers move into security consulting, vulnerability research, or security-focused venture capital.
Industries
Consumer technology companies (social, e-commerce, fintech, healthcare) handling sensitive user data, SaaS companies where application vulnerabilities could expose customer data, payment processors and financial institutions with PCI DSS requirements, gaming companies, and developer tool companies where a security vulnerability could compromise every customer using the product are the primary employers. Defence contractors, government technology companies, and any organisation that has experienced a significant breach and is rebuilding its security posture also have elevated product security hiring demand.
How to stand out
A CVE record, a bug bounty hall of fame mention, or a published security research finding demonstrates practical security depth over theoretical knowledge. Being specific about the vulnerability classes you have found and fixed in production code — not in CTF challenges but in real software — shows applied skill. Remote candidates who demonstrate experience building scalable security processes — security guidelines that engineers actually follow, security training that changed behaviour, automated security gates that caught real bugs — show the leverage orientation that product security requires in fast-moving engineering organisations.
FAQ
What is the difference between product security and infrastructure security? Product security focuses on the security of the applications that the company builds and ships — the code, the APIs, the authentication systems, the data handling logic. Infrastructure security focuses on the security of the systems and networks that the applications run on — cloud configuration, network security, identity management, endpoint security. Both are required for a complete security programme; the split reflects the different expertise required. Product security engineers need to understand software development deeply (they are essentially developers who specialise in security); infrastructure security engineers need to understand cloud architecture and network security deeply. At smaller companies one security engineer covers both; at larger ones the functions specialise.
What is a threat model and why do product teams use them? A threat model is a structured analysis of how a system could be attacked — who the potential attackers are, what assets they might target, what attack vectors they could use, and what controls exist to prevent or detect those attacks. Product teams use threat models when designing new features or systems to identify security risks before implementation (when they are cheapest to fix) rather than after deployment (when they require patches, incident response, and potentially user notification). The STRIDE methodology (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is the most widely used framework for systematically identifying threat categories against a given system design.
How does shift-left security work in practice? Shift-left security means moving security activities earlier in the software development lifecycle — from production scanning and penetration testing (done at the end of development) to developer education, secure code review, and automated security gates in CI/CD (done during development). In practice this requires: (a) security champions embedded in engineering teams who understand security and can advise peers; (b) SAST tools integrated in CI pipelines that catch common vulnerability patterns before merge; (c) dependency scanning that alerts on known-vulnerable libraries; (d) security review as part of the design process for significant new features (threat modelling); and (e) security training and guidelines that build secure coding habits across the engineering organisation. The goal is making security everyone's responsibility rather than a gate at the end.