zeroRISC
I have spent enough time in fundraising conversations, both as a founder and in conversations with other hardware security founders, to notice a pattern in how investor due diligence on hardware security has evolved. Three years ago, the security questions in a hardware startup diligence process were mostly about product-market fit and whether enterprise buyers would pay for security features. Today, sophisticated investors are asking significantly more specific technical questions — and the founders who answer them credibly close rounds faster.
This is not universal. Many investors still do not know what a hardware root of trust is, and that is fine. But at the intersection of hardware, security, and deep tech — where Fontinalis Partners and their peers invest — the diligence bar has risen. Here is what I am hearing, and how to think about it.
"What Is Your Threat Model?"
This is the question that separates teams who have done the hard thinking from teams who have assembled a security feature list without a coherent underlying architecture. A threat model is not a list of security features. It is a structured analysis of what assets the system is protecting, who the relevant adversaries are, what capabilities those adversaries have, and which attacks your architecture is designed to prevent, detect, and recover from.
The right answer to this question is a document — not a verbal answer. If you do not have a published threat model, the implicit message is that your security architecture is aspirational rather than systematic. Investors who understand security will infer that your threat model is informal at best, and that your security architecture probably has gaps that a formal analysis would reveal.
For hardware security companies building on RISC-V, a well-structured threat model should cover: physical access attacks (including fault injection and side-channel analysis), supply-chain compromise scenarios, firmware attack vectors, network-based attacks against devices in deployment, and key management failures. If your architecture has explicit, documented positions on each of these, you have a threat model. If you have not thought through all of them, now is the time — before you are in a diligence conversation.
"How Do You Know Your Security Claims Are True?"
This question is about evidence, not assertions. It is easy to write a datasheet that says "hardware-enforced security" or "tamper-resistant key storage." What investors who understand hardware security are asking is: what independent verification supports those claims? Has a security research team performed penetration testing? Has the architecture been reviewed by an external expert? Has it been certified against a recognized standard?
The honest answer for most seed-stage hardware security companies is that formal third-party validation is in progress rather than complete. That is acceptable — if the design methodology demonstrates that claims are verifiable in principle, even if full certification has not yet occurred. An open architecture that can be audited is more credible than a closed architecture with a certification badge, precisely because the credibility of the open architecture does not depend on trusting the certifier.
The answer that ends conversations is "our security is based on proprietary methods that we cannot disclose." Sophisticated investors in security companies know what that means: the security claims are not verifiable, and the architecture has not been tested by adversarial parties who know what they are looking at.
"What Happens When You Are Wrong?"
Every security system eventually encounters a vulnerability. The question is not whether your architecture is perfect — no architecture is — but whether it is designed to handle imperfection gracefully. Investors who have worked through security company failures know that the difference between a recoverable vulnerability and a company-ending one is usually not the severity of the flaw, but the quality of the response infrastructure.
For hardware security specifically, the answer to this question should cover: how firmware vulnerabilities are discovered (internal security review, bug bounty, external research), how they are patched (over-the-air update infrastructure with hardware-anchored integrity verification), how affected customers are notified, and what the SLA is for critical vulnerability remediation. For hardware flaws that cannot be patched via firmware update, the answer needs to address the more difficult question of hardware replacement or mitigation.
Having this infrastructure in place before it is needed is both technically and commercially important. Enterprise customers selling into regulated industries will ask the same question during procurement, and will want to see the answer in writing.
"Why Does Open Source Make You More Secure, Not Less?"
This question comes up specifically for companies — like zeroRISC — whose security architecture is built on open-source foundations. The implicit concern is that if adversaries can read the architecture, they have an advantage. The correct answer addresses why this intuition is wrong for security infrastructure, and why it is especially wrong for hardware security.
Security through obscurity is not real security — that argument is well-established in software security, and it applies with equal force to hardware. An open security architecture that has been reviewed by hundreds of competent security researchers is more likely to have known flaws than a proprietary architecture, in the same way that open-source cryptographic libraries have had more vulnerabilities disclosed than proprietary ones. But that is because the flaws in open systems get found and fixed, while the flaws in closed systems get found by adversaries and exploited.
The more important point for hardware security specifically: the value of an open architecture is that claims can be independently verified. Enterprise customers in regulated industries cannot simply take a vendor's word that their security architecture meets requirements — they need to be able to verify it. An open architecture enables that verification. A closed architecture requires trust. For security infrastructure, verifiability beats trustworthiness every time.
The Due Diligence Opportunity
The rise of more sophisticated hardware security due diligence is, counterintuitively, good for founders who have done the work. When the diligence bar was low, competitive differentiation was hard because every hardware security company could make unchallenged claims about security capabilities. When the diligence bar is high, the companies with genuine technical depth stand out clearly from those with security-by-marketing.
The founders I have seen navigate this environment successfully share a common trait: they welcome technical due diligence rather than trying to manage it. They publish their threat models. They describe the validation their architecture has received. They explain clearly what their architecture can and cannot protect against. They treat security claims as engineering commitments rather than marketing assertions.
That posture is not just good for fundraising. It is the posture that produces better security architecture, better customer relationships, and a business that can survive the inevitable moment when a vulnerability is discovered and the response infrastructure is what matters.
Building hardware security infrastructure and thinking about your architecture? The zeroRISC team is always happy to talk through hard problems.