The First 90 Days in a Product Security Role at a Medical Device Company

When I joined a medical device manufacturer as Product Security Officer, I spent some of my first weeks working through the quality management system, written against ISO 13485, which sets out how the organisation designs, builds, releases and monitors a product that goes into clinical use.

Not a threat model, an architecture review, nor a backlog of vulnerability findings waiting for someone to triage them.

I had come from sales, finance, IT operations and cybersecurity consulting, none of it in medical devices, and in every one of those environments security was a function that lived beside the business and argued for attention. You built the case and competed for budget and when leadership changed, you rebuilt the case in whatever terms the new leadership responded to.

What I understood, reading it, was that the argument had already been won. There was a quality management system with formal authority over how the product got built, and cybersecurity plugged into it. Safety was not a value on a wall. It was a documented, audited process with owners, records and consequences, and it had been that way long before I arrived.

So my job was not to convince anyone that rigour mattered. It was to learn to work inside rigour that already existed and already outranked me.

That is the single biggest adjustment for anyone moving into this role, and almost nobody tells you about it in advance.

What makes this different from IT security in other fields

Three things separate product security in a medical device company from the security work most people arrive having done.

• The first is what you are protecting. Not data, uptime, nor reputation, though all three still matter. It is a patient. When you assess a vulnerability, the question that carries most weight is what it does to the safety and effectiveness of a device in use. A critical CVSS score and nothing else will not move anyone.

• The second is time. In enterprise IT you patch on a schedule you largely control. A device in a hospital may run for ten to fifteen years, in a configuration you do not own, under a change control board that treats modification as a regulated activity. Post market is not the tail end of the job. Most of the security work on a device happens after it ships, not before.

• The third is who gets a say. Regulators are participants in your design decisions, not an audit event you prepare for twice a year. If your company ships into multiple markets, and most do, you are working against FDA expectations, EU MDR, China NMPA requirements and others at the same time, on the same product, with the same evidence base. Nobody holds all of that alone.

Who the real stakeholders are

You will map the obvious relationships quickly. Security engineers, software architects, systems engineering, product managers who own the product end to end, project managers who own delivery. Those relationships will fill your calendar, and you should build them properly.

The three below are the ones people coming from IT backgrounds underestimate, and they are the ones that determine whether you succeed.

• Quality: Quality owns the system your work lives inside. They can tell you where a security activity belongs in the design control sequence, what evidence has to exist, and why. You need this early, because the fastest way to be ignored is to propose an activity that has no defined place in the process.

• Regulatory affairs: They hold the multi market picture in their heads. If your company ships into several markets, and most do, someone is reconciling FDA expectations, EU MDR and China NMPA requirements against the same product and the same evidence base. That someone is usually them. They also know what has already been submitted and claimed, and which of your concerns has a regulatory consequence and which does not. Treat them as a gate to clear and you will spend your first year fighting the wrong battles. Treat them as the colleagues who translate your work into the language that markets accept, and they become the most valuable relationship you have.

• Service and field engineers: They know how devices actually behave in hospitals. What gets left connected, what gets unplugged, what workaround the clinical staff invented in week two. They also tend to see the first real world signal when something is wrong, which means working out how that signal reaches you is a first ninety day task, not a later one. Your threat model is a hypothesis until it meets their evidence.

What to read in month one

Read in three tiers, roughly in this order.

Tier one, public standards and guidance: Start with ISO 14971 first, because risk management is the centre of gravity and every security standard here orbits it. Then ISO 13485 for the quality system your work sits inside, IEC 62304 for the software lifecycle, and IEC 81001-5-1 for security activities across that lifecycle. AAMI TIR57 for applying risk management to security specifically, and AAMI SW96 for security risk management across the product lifecycle. Alongside these, read the current premarket and postmarket cybersecurity guidance from the markets your products ship into. This tier is public, it is durable, and it is the vocabulary everyone around you is already speaking.

Tier two, your own product artifacts: The risk management file, the architecture and design documentation, the software bill of materials if one exists, prior assessments and audit records. Read to understand the safety argument the product is making, not to find fault. You will find plenty. It can wait.

Tier three, what the product has already promised: Released documentation, service manuals, and any customer facing security documentation. This is what your organisation has publicly committed to about the product's security behaviour. Very few new people read it, and it is often where the gap between claim and reality is easiest to see.

Earning credibility with engineering

Learn the product before you have opinions about it. Ask an engineer to walk you through their subsystem, then keep asking until you can describe it back to them correctly and they agree that you have it right. That exchange, repeated across a handful of subsystems, buys more standing than any assessment you could produce in the same weeks.

Do not lead with findings. A new security person arriving with a list is the most predictable event in an engineering team's year, and they have already decided how to absorb it. Arrive with questions for long enough that your first finding lands as a contribution rather than an inspection.

Translate in both directions. This is the actual job and almost nobody else is doing it. Take a security concern and express it as the design constraint or safety property it violates, so engineering can act on it. Then take engineering's objection, which is usually about sequence, feasibility or verification cost, and express it back to the risk and regulatory side in terms they can act on. If you came from consulting, sales or any client facing background, this is where that history stops being a gap in your CV and starts being an advantage.

Deliver one small useful thing inside ninety days. Something that removes work from an engineer rather than adding it. A reusable requirement set, a clarified process step, a component inventory someone else was dreading. Small and finished beats large and pending.

And find the person who will spend some social capital on you early. Then be worth it.

Ninety days in

The mistake is to treat the first ninety days as a period in which to demonstrate value. It is a period in which to become able to add it.

Learn the safety argument the product is making. Learn who holds which part of the picture. Learn the vocabulary well enough that your concerns arrive in a form the organisation can act on. Everything you want to change will still be there in month four, and by then you will know which changes are worth the cost.