Security Firmware

1What you'd actually do

• Writing and debugging C (and some assembly) that runs on a microcontroller or a secure element — code with no operating system underneath it, or a very small real-time one, where you manage memory yourself and there is no crash log to read afterwards.
• Working with hardware directly: flashing a development board, attaching a debug probe (JTAG/SWD) to step through code on the chip, reading datasheets and reference manuals to work out which register controls which peripheral.
• Implementing or integrating security features such as secure boot (checking a digital signature on the next stage of software before running it), firmware update mechanisms that can't be downgraded to an old vulnerable version, and key storage that survives someone physically probing the board.
• Reading and reasoning about attacks: thinking through what happens if an attacker glitches the power supply at exactly the wrong moment, feeds in a malformed input, or reads out flash memory, and then changing the code so those cases fail safely.
• Reviewing colleagues' code and writing tests — unit tests, hardware-in-the-loop tests, and sometimes fuzzing (throwing malformed inputs at an interface to see what breaks).
• Sitting with hardware engineers, cryptographers and product teams to agree how a feature will work before it is committed to silicon or to a release, because firmware often has to compensate for things the hardware cannot do.
• Producing evidence for certification or customer audits — threat models, design documents, test results — particularly in payments, automotive and defence where a product must be assessed against a standard before it ships.

2How graduates get in

• Graduate schemes at semiconductor, embedded systems, defence and telecoms companies. Most advertise as 'embedded software engineer' or 'firmware engineer' rather than mentioning security in the title, and place you into a security team once you join — so search on the broader terms.
• Direct entry as a junior embedded/firmware engineer, then moving sideways into security work after a year or two. This is probably the most common route, because security firmware teams often prefer people who can already write reliable low-level code.
• Industrial placement years and summer internships in embedded or hardware teams. These matter a lot in this field — a placement year at a chip or device company is one of the strongest things you can have on a CV for these roles.
• Via cyber security graduate schemes at large engineering or defence employers, which rotate you through areas including hardware and firmware security. Less common as a direct route into firmware specifically, but it happens.
• Via an MSc in embedded systems, cyber security or hardware security, especially if your first degree was maths or physics rather than engineering. Useful but not required — an MSc is a way in, not the standard way in.
• Degree apprenticeships in electronic or software engineering, which some readers will already be on. Unusual as a graduate route but a well-established alternative to a degree for this kind of work.

3What employers ask for

• A degree in computer science, electronic/electrical engineering, computer engineering, or a closely related numerate subject. The subject genuinely matters more here than in many graduate jobs — employers want you to have seen C, computer architecture and how a processor actually executes instructions.
• Practical evidence that you can program in C. This is the single most common filter. Personal projects on an Arduino, Raspberry Pi Pico, STM32 or similar count, as do university coursework and placement work.
• A 2:1 is the common asking grade at larger employers, with some asking for a 2:2 plus strong practical evidence. Smaller companies and consultancies often care more about what you can demonstrate at interview than your classification.
• Security knowledge is usually expected at an awareness level rather than an expert one — understanding what a hash, a digital signature and symmetric versus public-key encryption are, and why you never write your own crypto. Deep cryptography knowledge is a specialism you build later.
• For defence, government and some telecoms work you will need UK security clearance, which normally requires British nationality or long-term UK residency and a period of residency history. This rules some roles out for some candidates, so check job adverts early.
• Formal certifications are rarely required to enter. Chartered Engineer status through the IET or BCS, and security certifications, are things people pursue later in their careers rather than before applying.

4Skills that matter

5Where it leads

1. Graduate/junior firmware engineer: you work on well-scoped pieces of an existing codebase — a driver, a test harness, a bug fix — under close review while you learn the toolchain, the hardware and the company's security requirements.

2. Firmware or security engineer: you own components, take features from requirement to shipped code, review others' work and start attending design discussions with hardware and product teams. Reaching this point commonly takes a couple of years but varies a lot with employer size and how much you're exposed to.

3. Senior engineer: you own the security architecture of a subsystem or product, define the threat model, and are the person consulted when someone asks whether a proposed change is safe. Timelines here vary widely and depend far more on the breadth of work you've been given than on years served.

4. From senior level the paths fork. Technical routes include principal/staff engineer, security architect, cryptography specialist, or moving into hardware security research and vulnerability work. Management routes include leading a firmware team or running an engineering function.

5. Sideways moves are common and valued: into product security consultancy, penetration testing of embedded devices, secure hardware design, standards and certification work, or automotive/payments security specialisms. Experience in low-level security transfers well because relatively few engineers have it.

6Where this varies

The job varies a lot by sector. At a semiconductor or chip design company you may work on generic security building blocks — a secure boot ROM, a cryptographic accelerator driver — that many customers will later use, with long lead times and no chance to patch once silicon ships. At a device manufacturer (payments, automotive, medical, smart metering) you are integrating those building blocks into a specific product and dealing with certification schemes and regulators, which means significantly more documentation and formal test evidence. At a security consultancy you may be reviewing and attacking other companies' firmware rather than writing it, working across many short projects. Defence and government-facing work adds clearance requirements and restrictions on what you can discuss, and the pace is generally slower and more process-heavy. Team size also changes the job: at a small company a graduate may touch hardware bring-up, firmware, tooling and customer support in the same week, whereas at a large employer the role is narrower and more specialised from the start.