Open a banking app on a phone. It asks for a fingerprint or a PIN, and sometimes an OTP by SMS. Once inside, a person sees their own accounts and nobody else's. Linking the account to a budgeting app happens without ever handing that app the password. If someone abroad tries password after password on the account, the attempts are blocked and the owner gets an alert.

An attacker looks at the same app and sees four ways in. The code might have a flaw that lets one customer read another's statement. The login might be tricked into letting the wrong person in. The cloud servers holding customer data might be left open by a careless setting. The traffic between the phone and the bank might be read or tampered with on the way.

One security software engineer looks after all four. They review the code of a new feature for flaws and add scanners to the build pipeline that catch weak spots before it ships. They set up the login with standards like OAuth 2.0 and OpenID Connect, which let one app act for a person in another app without ever seeing the password, and write the rules for who may see which account. They check that the cloud servers are locked down, and that every connection is encrypted and every unusual pattern of traffic raises an alarm.

The work involves four kinds of skill, and every security engineer holds all of them in some measure, with one or two usually deeper than the rest. Each one borrows from a neighbouring role.

Securing the code is the closest to ordinary development. The engineer studies a feature's design for ways it could be abused, which engineers call threat modelling, reviews code against the OWASP list of the most common weaknesses in web applications, and runs tools that scan code and probe a running app, such as Burp Suite and SonarQube. This side draws on the skills of a backend engineer or a frontend engineer.

Securing the logins means building the systems that decide who someone is, called authentication, and what they may do, called authorisation. It covers single sign-on, so staff log in once to reach every company tool, multi-factor login, and products such as Okta and Active Directory. This is backend work focused on one problem, often in Java.

Securing the cloud means making sure cloud accounts, containers and the pipeline that ships code are set up safely, that passwords and keys are kept out of the code, and that the Terraform code which builds the servers cannot open a door by mistake. It sits right beside the work of a cloud and DevOps engineer, and is often called DevSecOps.

Securing the network covers firewalls, the tools that spot an intruder, and the encryption that protects data on the move. It is the closest to the hardware and draws on the skills of a C/C++ systems engineer.

Python is the language named most across the role, for scanners, tools and automation, with Java close behind, then Go and C/C++. Before a feature is built, the engineer agrees with the product and backend teams how it should handle logins, data and access.

In smaller teams one security engineer covers all four kinds of skill. In bigger companies the depth turns into job titles of its own, and readers will meet them in job posts. An identity and access engineer, often shortened to IAM engineer, works almost only on logins and permissions. An application security engineer, sometimes called a product security engineer, works with development teams on the code. A cloud security engineer secures the cloud and the pipeline, and a network security engineer looks after firewalls and traffic. Services firms also hire specialists to set up identity products such as Okta or SailPoint for their clients.

At security product companies, like Palo Alto Networks, Zscaler, CrowdStrike and Okta, security is the product itself. Engineers there build the firewall, the login platform or the attack detector that other companies buy, so their work looks much like any product developer's, in a field where every customer is a target.

Around the building sits a set of duties that every security software engineer shares.

Incidents pull everyone in. When a real attack or leak is suspected, security engineers join the response, read the logs, close the hole and write up what happened. Many take turns on call for exactly this.

Security engineers spend a lot of time teaching. They review other teams' code and designs, write guides on safe coding, and run short training sessions so developers stop common mistakes before they reach a review.

Compliance is part of the job in banks, payments and healthcare. Regulators and auditors ask for proof that systems are protected, so engineers gather that evidence, answer audit questions and keep security policies up to date. Some teams also invite penetration testers, who attack a system on purpose and with permission to find weak spots before real attackers do, and then fix what they find. New attacks and weaknesses are published every week, and engineers check each one against the company's own software.

A cloud and DevOps engineer builds and runs the platform, and the security software engineer makes sure nobody can misuse it. A test engineer checks that software does what it should, while a security engineer checks that it cannot be made to do what it should not. A backend engineer builds the application, and the security engineer designs the login and access around it. A security analyst, who watches alerts in an operations centre, does related work that is closer to monitoring than to building.

The ideal candidate looks at any system and wonders how it could be broken. Engineers usually arrive after some years as developers or cloud engineers, since securing software means understanding how it is built. Senior engineers become security architects, who decide how a company's systems are protected, or go deep in one area such as identity, cryptography or penetration testing.