Independent review
Firmware Code Audit and Independent Technical Review
Kyros Engineering performs independent firmware audits on code you did not write — contractor deliveries, inherited designs, and acquisition-stage due diligence. You get a written assessment of architecture, risk, testability and maintainability, with findings evidenced on the actual hardware where the hardware is available, and a plain recommendation on whether to keep, repair or replace.
Scope this with usSomeone hands you a repository and a claim that it works. The question is not whether it compiles — it is whether you can ship it, maintain it, certify it, and sleep.
That question is uncomfortable to answer from inside the team that commissioned the work, which is precisely why an independent read is worth what it costs.
What an audit actually covers
We read for the things that determine whether code is an asset or a liability.
- Architecture — whether the structure matches the problem, or fights it
- Failure behaviour — what happens on power loss, comms loss, sensor loss, and whether that was designed
- Testability and the verification evidence that does or does not exist
- Maintainability by your team specifically, given who you actually have
- Hidden coupling, undocumented assumptions and single points of knowledge
- For regulated products, whether the lifecycle record could support a submission
Evidence, not opinion
Where hardware is available we reproduce the important findings on the bench rather than asserting them from a read. A finding you can demonstrate is a finding your vendor cannot argue with, and it is the difference between a review that changes a decision and one that becomes another document.
AI-generated code is now a normal finding
A growing share of contractor-delivered firmware contains substantial generated code. It is often superficially clean and locally plausible while being wrong about the specific hardware — peripheral configuration copied from a different part, timing assumptions that do not hold, and error paths that were never reasoned about. We check for it explicitly, because it fails differently than hand-written code and it fails in the field rather than in review.
When to call
You probably want this if…
Frequently asked
What do we actually receive?
A written report: architecture assessment, prioritised findings with severity, evidence for the significant ones, a maintainability read, and a direct recommendation on keep, repair or replace. It is written to be readable by your engineering leadership and defensible in front of the vendor.
Will you take over the code afterwards?
We can, but the audit is deliberately separable and is not a sales device for a rewrite. Recommending a rewrite when a repair would do is the easiest way for a firm like ours to lose the trust that makes the audit worth anything.
Can you audit without the hardware?
Yes, and we will say clearly in the report which findings are evidenced on hardware and which are read from the source alone. The distinction matters, so we never blur it.
How long does an audit take?
Most fit the two-week architecture diagnostic at $6,000. Large or safety-critical codebases scope individually, and we tell you the range before you commit rather than after.
Holding a repository you cannot vouch for?
Send us the scope. You will get a straight answer, including if the answer is that it is fine.