Key takeaway: SR&ED for hardware startups runs through the same two-part CRA test as any software claim: technological uncertainty, resolved through systematic investigation. Building a prototype doesn't automatically qualify, and moving to commercial production actively disqualifies the work — the CRA excludes "commercial production" and routine "style changes" by name. What tips a hardware claim in your favour is different from a software claim in one concrete way: physical capital equipment and prototype builds carry their own cost rules, restored for property acquired after December 15, 2024. Get the eligibility line right first. The dollars follow from there.
Hardware founders tend to assume the opposite of what's actually true. A team that spent eighteen months bringing up a physical product often figures the whole build was R&D — it was hard, it was expensive, and nothing about it felt routine. Meanwhile a team running the exact same experiments in software would list them out project by project without a second thought. The CRA doesn't grade on difficulty or dollars spent. It asks one question about every hour of work: was the outcome actually unknown, or just unbuilt yet?
This post covers where that line falls for a company building physical products — sensors, robotics, devices, industrial equipment, anything with a bill of materials — including the parts that are genuinely different from a pure-software claim: capital equipment, prototype builds, and contract manufacturing.
Does SR&ED cover hardware development work
Yes, hardware development can qualify for SR&ED, but building a physical thing isn't the test any more than writing code is. The test is the CRA's two-part standard, applied the same way to a PCB layout as to a database schema: was there a technological uncertainty that standard engineering practice couldn't resolve, and did you attack it through systematic investigation instead of iteration for its own sake.
Per the CRA's eligibility guidance, the "why" is advancement of scientific or technological knowledge against genuine uncertainty; the "how" is systematic investigation by experiment or analysis. Engineering and design both sit inside the eight recognized categories of support work, alongside computer programming, operations research, mathematical analysis, data collection, testing, and psychological research. A thermal-management problem or a novel actuator design gets evaluated on the same terms as a compiler team's work. There's no separate hardware track.
Where the line actually falls, and where it explicitly stops
Here's the part that makes hardware claims sharper-edged than most software claims: the CRA doesn't just describe what counts. It names, specifically, the moment hardware work stops counting. Excluded activities include commercial production, quality control or routine testing, and style changes — three categories that map almost exactly onto the hardware product lifecycle.
Building and testing a prototype where the mechanical, thermal, or electrical behaviour genuinely wasn't predictable in advance is squarely eligible territory. Debugging why a sensor's readings drift outside spec under vibration nobody had characterized for your exact assembly, and running structured tests across material and mounting variations to isolate the cause, is systematic investigation against real uncertainty. Ramping the same design to a production line, where the goal shifts to yield, throughput, and repeatability rather than resolving an unknown, is commercial production — explicitly out. Swapping a component's casing colour or connector shape without touching function is a style change — also explicitly out, by name, in the CRA's own list.
That handoff point — prototype to production — is where more hardware claims go wrong than any other single issue. Work done to bring a known-working design up to manufacturing scale is valuable, often genuinely difficult engineering. It's also, per the CRA's own excluded list, not what this program funds.
Worth flagging: the specific examples above (vibration-drift debugging, mounting-variation testing) are our application of the general test and the excluded-activities list to a hardware scenario, not a CRA-published hardware bulletin — there isn't one. The exclusions themselves are exact quotes from CRA guidance; how they play out on your specific build is a judgment call, same as any other claim.
What usually doesn't qualify
Most of what a hardware team ships day to day is still ordinary engineering, whatever the bill of materials looks like.
Selecting an off-the-shelf microcontroller, sensor, or motor from a datasheet and integrating it per the manufacturer's reference design is applying known technology, not advancing it — the uncertainty about whether the part works as specified was already resolved by the vendor's own characterization. Building a test jig to verify units meet a spec you've already defined is quality control or routine testing, even when the jig itself took real engineering effort to build. Tooling up a production line, sourcing a second supplier for an existing part, or hitting a cost-reduction target by substituting known-equivalent components is commercial production and process engineering, not technological uncertainty.
None of that makes the work unimportant — a bad supplier switch can sink a hardware company as fast as a bad claim can. It just isn't SR&ED. The distinction that matters is uncertainty versus difficulty, and hardware teams conflate the two more than most, because physical builds are expensive and slow enough that everything about them feels hard-won.
Where the uncertainty actually shows up
A quick filter: would a competent engineer at a comparable company have been able to predict the physical behaviour before you built and tested it? If yes, it's probably not SR&ED, no matter how many prototype revisions it took to get there.
Real hardware uncertainty tends to cluster around a handful of recurring problems. A thermal, mechanical, or electromagnetic interaction that doesn't behave the way datasheets or standard reference designs predict once your specific combination of components and enclosure comes together. A materials or manufacturing-process question where the documented approach doesn't hold at your tolerance, volume, or environment — and you run structured trials across variables to isolate what's actually driving the failure. A power, weight, or size constraint that no published architecture hits simultaneously, forcing genuine trade-off experimentation rather than picking from a known menu. Sensor fusion or control-system behaviour that's unstable in ways standard tuning doesn't fix, requiring a systematic search rather than trial-and-error twiddling. In every case, the tell isn't that a part failed. It's a documented record: a hypothesis about why, a test designed to check it, a result, and what changed next. The CRA is explicit that a project doesn't need to succeed to qualify — a prototype revision that failed for a specific, documented reason is evidence, not a liability.
Two hardware startups, two different claims
Picture two companies that both build physical products and would both describe themselves as "hardware" without hesitation.
Company A builds an environmental sensor for indoor air quality. It selects a well-documented off-the-shelf sensor module, wires it to a microcontroller using the reference schematic, and spends its engineering effort on enclosure design, firmware polish, and a companion app. The product might be well made and commercially strong, but nothing about the sensor's underlying behaviour was uncertain going in — the module's datasheet describes exactly how it performs. If Company A files a SR&ED claim on this build, it's likely thin, because there isn't much "why" to point to.
Company B builds a ruggedized version of a similar sensor for underwater deployment, where the standard module's readings drift unpredictably under pressure and temperature swings no manufacturer characterizes for that environment. The team runs structured trials across sealing methods, calibration approaches, and compensation algorithms, discarding several before landing on one that holds accuracy within spec across the target range — with a documented log of what was tried and why each attempt fell short. That record is what makes Company B's claim strong, not the fact that its product also happens to be a sensor.
Neither company is more of a "hardware company" than the other on a pitch deck. Only one of them ran into and resolved a real technological unknown, and that's the whole difference for SR&ED purposes.
Capital equipment and prototype costs
This is where a hardware claim genuinely diverges from a software one, and it's worth understanding on its own. For years, capital expenditures were excluded from SR&ED entirely — a gap that mattered a lot more to a company buying test rigs, tooling, or specialized lab equipment than to one paying only for engineer salaries and cloud compute.
That gap closed. Capital property acquired after December 15, 2024 is eligible for SR&ED again, per the CRA's investment tax credit policy, restored as part of the Bill C-15 changes that received royal assent in March 2026. The 35% enhanced rate on qualifying capital expenditures is 40% refundable — narrower than the 100% refundability on current expenditures like salaries, but real money on equipment a hardware team was already going to buy.
What this means in practice: a test chamber, a specialized fixture built to characterize the exact failure mode you're investigating, or lab equipment bought specifically to run your experiments can now enter the claim if acquired after the December 2024 cutoff, on top of the engineering salaries already at the core of most claims. Equipment bought before that date, or used for production rather than the experimental work itself, is a different and more limited picture — this is a genuine area where a hardware team's claim benefits from someone who tracks acquisition dates and use against the $6 million expenditure limit deliberately, not from guessing.
Where contractors and contract manufacturers fit
Pay an outside firm or a contract manufacturer to build or test experimental hardware on your behalf, and only 80% of that arm's-length contract spend enters your qualified expenditure pool — the full invoice doesn't count. That rule has applied since 2012 and doesn't bend because the deliverable is a physical part instead of a software module.
Whether the 80% rule even applies turns on the substance of the arrangement, not what the purchase order says: did the contract require specific experimental work with real technical risk, or was it a fixed-scope build to a spec you'd already fully defined? Who carried the cost risk if a manufacturing run failed to meet tolerance? Hardware teams that send experimental builds to a contract manufacturer or fabrication shop should get that scoping — and who owns the resulting IP — settled in the contract itself. It's the fact pattern a reviewer looks at, not a story written after the invoices are already paid.
The overhead question
Salaries for the engineers running the experiments are the core of most hardware SR&ED claims, and the CRA's proxy method adds an overhead allowance without requiring line-item tracking of every expense. The prescribed proxy amount has been 55% of your SR&ED salary base since 2014, meant to approximate overhead like admin support rather than making a team itemize lab rent, shop tooling, and every software licence separately.
That 55% doesn't automatically absorb everything a hardware build racks up. Materials consumed in prototype iterations, specialized test equipment, and now restored capital purchases each interact with the claim differently, and getting that categorization right — what's a current expenditure, what's capital, what the proxy already covers — is a real question with real dollars on either side of the answer. Worth resolving deliberately with whoever prepares your claim, not assumed away.
What hardware teams get wrong about documentation
The most common failure mode isn't ineligible work; it's eligible work with no evidence trail, and hardware teams are especially exposed to this because so much of the real record lives outside a ticketing system — in lab notebooks, test-bench photos, a shared spreadsheet of failed builds, or a group chat where someone posted an oscilloscope screenshot at 11pm.
A prototype log that reads "rev 4 works, shipping" doesn't show what rev 3's failure actually was, why the team expected a different result, or what specifically changed. A CRA reviewer isn't an electrical engineer or a materials scientist by default; they're reading the narrative to understand whether real uncertainty existed and whether you investigated it methodically. Hardware teams that already keep detailed build logs and test records for their own engineering process are usually sitting on most of the raw material for a strong claim. It just needs to be captured as it happens and translated into SR&ED's language, not reconstructed eighteen months later from a folder of loose CAD revisions and a Slack channel nobody thought to search.
Who should think twice before claiming
Skip this, or claim carefully, if your hardware work is mostly assembling documented components per their reference designs, with the engineering effort going into enclosure aesthetics, cost reduction on a working design, or scaling a proven build to volume. The same goes if the honest answer to "what was uncertain here" is "we weren't sure which supplier to use" or "we weren't sure the market wanted this form factor." Those are real business risks. They aren't technological uncertainty.
Plenty of hardware teams also get it backwards the other direction, assuming that because their product looks unglamorous — an enclosure, a bracket, a sensor mount — none of the underlying engineering could possibly qualify. If your team ran into a genuine mechanical, thermal, or materials unknown and tested its way through it with a documented trail, that's exactly the kind of experimental development the program is built for, whatever the product looks like from the outside.
What SR&ED for hardware startups is actually worth
The rates don't change because the uncertainty happened to resolve in metal and silicon instead of code. A Canadian-controlled private corporation earns the enhanced 35% refundable rate on up to $6 million of qualifying expenditures a year, for tax years beginning after December 15, 2024, with the basic 15% rate applying beyond that. At the enhanced rate, that's as much as $2.1 million a year. Credits on current expenditures like salaries at the 35% rate are 100% refundable up to the limit for most CCPCs — cash even against zero tax owing — while capital expenditures at that same rate are 40% refundable, and excluded corporations receive a 40% refund on current expenditures instead of 100%.
The clock is identical too: a corporation's SR&ED reporting deadline is 18 months after its fiscal year end, with no extension process available. A hardware team mid-tooling-run, heads-down on getting a production line stood up, is exactly the kind of company that lets that date slip — and reconstructing why a prototype revision failed eight months and three design changes ago is a lot harder than a software team reconstructing a training run's logs.
That's the part of the job that doesn't care whether the R&D produced a device or a database index: continuous documentation, captured from the tools and records your team already keeps, reviewed by a qualified independent SR&ED expert before anything is filed. Automation on our side handles the collecting; a named human still stands behind what goes in front of the CRA. It doesn't decide whether your prototype work qualifies — that's still the two-part test — but it means the evidence exists when the claim gets built instead of getting rebuilt from a folder of loose test photos.
Frequently asked questions
Does building a physical product automatically qualify for SR&ED? No. The CRA's eligibility test looks for genuine technological uncertainty resolved through systematic investigation, the same standard applied to software. Building hardware doesn't change the test; it changes what the uncertainty looks like.
Does moving from prototype to production disqualify the work? The transition itself is the line. Prototype work resolving a real technical unknown can qualify. Once the goal shifts to yield, throughput, and repeatability on a design that already works, that's commercial production — explicitly excluded by the CRA.
Is building a test jig or fixture eligible SR&ED work? Only if the fixture itself, or what you learn from it, resolves genuine uncertainty. A jig built to verify units meet an already-defined spec is quality control, which is explicitly excluded. A fixture built to characterize an unknown failure mode as part of investigating it can be part of a legitimate claim.
Do capital purchases like test equipment count toward a SR&ED claim? They can, for capital property acquired after December 15, 2024, per the CRA's investment tax credit policy. Capital expenditures were excluded for years before that date; the restored eligibility applies going forward, at a 40% refundable rate rather than the 100% rate on salaries.
Does using a contract manufacturer change what I can claim? Yes, if the manufacturer is arm's length. Only 80% of that contract payment enters your qualified expenditure pool, and whether it counts as a contract payment at all depends on the substance of the arrangement, not what the purchase order says.
Do failed prototype builds still count for SR&ED? Yes. The CRA's own eligibility guidance states a project doesn't need to succeed to qualify. A prototype revision that failed for a specific, documented reason is evidence of real uncertainty, not a reason to leave it out.
Hardware doesn't get an easier or harder SR&ED rulebook. It gets the same two-part test as everything else, with one sharp edge the CRA spells out by name: the moment a prototype becomes a production line, the claim stops.
See what your hardware engineering work could be worth — estimate your refund or check your eligibility.