Product Security Hub Logo

September 1, 2026

Your Engineers Won't Stop Using Excel. That's Fine.

Engineers keep going back to Excel. That's not the real problem. Here's what actually breaks when your security data lives in disconnected spreadsheets — and what it means for FDA submissions.

By Colin Morgan

I hear the same thing from every medical device company I work with. The product security lead loves the idea of a connected platform. Threat models, SBOMs, vulnerabilities, residual risks, all in one place, all traceable. They see the value immediately.

Then they try to get their engineering team to use it.

“They just keep going back to Excel.”

I’ve heard this from companies with 50 employees and companies with 50,000. It’s universal. And after years of working on this problem, I’ve come to a conclusion that might surprise you.

Stop trying to get them to quit Excel.

Excel Is Not the Problem

Engineers use Excel because it works for what they need to do in the moment. Fill in a row. Update a field. Sort by severity. Copy a tab and send it to someone. Excel is fast, familiar, and flexible. Nobody needs training to use it. Nobody needs to learn a new interface.

If all you need to do is fill in a threat model template or log a vulnerability, Excel is perfectly fine. I’m not going to pretend otherwise.

The problem isn’t Excel. The problem is what happens after the Excel work is done.

Where It Actually Breaks

An engineer fills in 40 threats in a spreadsheet. Another engineer documents 200 vulnerabilities in a different spreadsheet. A third person writes requirements in a third spreadsheet. Someone else tracks residual risks in yet another one.

Each spreadsheet is fine on its own. But now the security lead needs to answer a question: does every vulnerability trace back to a threat, and does every threat have a requirement that addresses it?

That question is unanswerable without manually cross referencing four files. And that’s where the real cost lives. Not in the data entry. In the connections between the data.

I worked with one manufacturer where the security team spent three weeks preparing for an FDA submission. They had everything documented. Threat models. Risk assessments. SBOM analysis. Vulnerability logs. All in Excel. All thorough.

The problem was connecting it. Making sure every vulnerability linked to the right threat. Making sure every residual risk referenced the right requirement. Making sure nothing slipped through the gaps between spreadsheets. Three weeks of work, and most of it was cross referencing, not analysis.

The worst part? After all that manual cross referencing, the process still revealed gaps they didn’t know existed. Requirements that weren’t mapped to any threat. Vulnerabilities with no associated risk assessment. Not because anyone was careless, but because spreadsheets don’t enforce traceability. They just hold data.

The Version Problem

There’s another issue nobody talks about. Spreadsheets don’t version well in a team environment.

ThreatModel_v2_final.xlsx. ThreatModel_v2_final_revised.xlsx. ThreatModel_v2_final_revised_JK_edits.xlsx. Everyone has lived this. Someone makes a change in their copy. Someone else makes a different change in theirs. A week later, nobody knows which file is current.

For personal task management, this is annoying. For FDA cybersecurity documentation, it’s a risk. If an auditor asks “show me the version history of this risk assessment” and your answer is “it’s in the filename,” that’s not a great position to be in.

What We Actually Need

The insight I keep coming back to is that the problem isn’t where people do the work. It’s whether the work connects.

An engineer should be able to work however they want. If that’s Excel, great. If that’s a web interface, great. If that’s Claude Code talking to an API, great. The input method doesn’t matter.

What matters is that when the work is done, the data lands in a system where it connects to everything else. Where a vulnerability automatically links to the component it affects. Where a threat traces to the requirements that address it. Where changing one record doesn’t silently break the relationships to others.

That’s the difference between a file and a system. Excel is a file. It holds data. A system holds data and knows how the data relates.

How We Handle This

The answer isn’t to force engineers out of Excel. It’s to make Excel a valid input into something better. That’s why we built import and export into every layer of Product Security Hub. Every record type has a standardized template you can download as Excel. Engineers can work in their spreadsheet, fill in the fields they know, and import it back into the platform. PSH validates the data, shows what’s going to be created or updated, and the engineer approves the import.

They never have to leave Excel if they don’t want to. But once the data is in PSH, it’s connected. The threat links to the component. The vulnerability links to the threat. The residual risk links to the vulnerability. The traceability exists structurally, not because someone manually typed a reference ID in column G.

When the security lead pulls up the dashboard, everything is there. FDA compliance by control category. Component risk breakdown. Gaps between threats and requirements. Not because someone spent three weeks cross referencing, but because the platform enforces the connections at import time.

And some things only become possible once the data is connected, not because they’re features, but because they require the whole picture at once.

When 200 new CVEs hit your SBOM, evaluating each one against your product’s architecture, trust boundaries, and design controls means the AI needs the threat model, the component relationships, and the security requirements all at the same time. You’re not going to paste your entire threat model into a spreadsheet formula. When an engineer updates a requirement, every linked threat and risk should reflect that change automatically, not after someone finds and updates every related cell by hand. When a security lead needs a compliance view before a submission, they need data that’s current, not a snapshot from last Tuesday.

None of that is about replacing Excel. It’s about what’s only possible when Excel isn’t the end of the line.

The Practical Takeaway

If your engineering team prefers Excel, don’t fight it. Give them better templates. Make import seamless. Let them work the way they want.

Then connect their work in a system that gives the security lead what they actually need: traceability, gap analysis, compliance views, and AI capabilities that only work when everything is in one place.

The goal isn’t to eliminate Excel. It’s to make sure the connections your auditor is going to ask for actually exist, and that you didn’t spend three weeks building them by hand the night before a submission.