IoT and embedded systems companies develop connected devices — combining hardware, firmware, sensors, communications, and software — for applications ranging from industrial monitoring to consumer products. The technical challenges can include developing firmware for resource-constrained environments, engineering hardware-software interaction, integrating sensors, optimizing power consumption, ensuring reliability and latency, and developing edge processing. This page explains what development work may look like in an IoT and embedded systems business and how it relates to qualified research under Section 41. It is educational and is not individualized advice.
What R&D May Look Like in IoT & Embedded Systems
IoT and embedded systems development involves firmware development, hardware-software integration, sensor and communication engineering, power optimization, and reliability development. Technical development may arise when a company develops new firmware for resource constraints, engineers hardware-software interaction, optimizes power consumption, or develops edge processing. Work directed at resolving genuine technical uncertainty in these areas — through a structured evaluative process — may warrant review under the four-part test.
Industry-Specific Examples of Technical Development
- Developing firmware for resource-constrained environments where the firmware performance is uncertain.
- Engineering hardware-software interaction where the interaction performance is uncertain.
- Integrating sensors and developing communications where the performance is uncertain.
- Optimizing power consumption where the power performance is uncertain.
- Developing edge processing where the processing performance is uncertain.
None of these constitutes qualified research by itself. Each depends on whether the work satisfies all four elements of the four-part test.
Technical Uncertainty Examples
- Whether a new firmware approach can achieve the specified latency and power targets simultaneously.
- Whether an alternative sensor integration can achieve the specified accuracy and reliability targets.
- Whether a modified communication approach can achieve the specified range and power targets.
For more, see our page on elimination of uncertainty.
Process-of-Experimentation Examples
- Implementing and testing alternative firmware approaches, measuring latency and power, and comparing results.
- Building and testing alternative sensor integrations, measuring accuracy and reliability, and evaluating results.
- Testing alternative communication approaches, measuring range and power, and comparing results.
For more, see our page on process of experimentation.
Potential Business Components
Potential business components may include a new or improved product (an IoT device with improved performance), a new or improved process (a firmware or communication process), or a new or improved technique (a sensor integration or edge processing method).
Employee Work That May Warrant Analysis
Employees whose work may warrant analysis include firmware engineers developing firmware, hardware engineers developing integration, embedded developers developing communications, and quality engineers conducting reliability and power testing tied to a development project. For more, see our page on R&D tax credit employee wages.
Contractor Work That May Warrant Analysis
Contractor work that may warrant analysis includes sensor and component suppliers, testing laboratories, and specialized consultants — where the company bears the economic risk and retains substantial rights. For more, see our page on R&D tax credit contractor costs.
Supplies and Materials That May Become Relevant
Supplies that may become relevant include prototype components, sensors, and consumable test materials. For more, see our page on R&D tax credit supplies.
Activities That Generally Require Caution or May Not Qualify
- Routine firmware updates and maintenance.
- Standard sensor selection and integration using established methods.
- Ordinary configuration and deployment.
- Copying an existing design for a new application.
- Normal quality control and testing following established procedures.
Documentation That May Help
Records that may help include project descriptions, firmware and sensor test results, power and reliability data, and records connecting personnel and materials to specific development projects. For more, see our page on R&D tax credit documentation.
Example Hypothetical Project
The following is a hypothetical example for illustration only. It does not represent any actual company and does not state that the work qualifies.
An IoT company is developing a battery-powered environmental monitoring device where the standard firmware approach does not achieve the specified battery-life and latency targets. The technical uncertainty is whether an alternative firmware architecture, a modified sensor sampling approach, and a new communication protocol can together achieve the battery-life, latency, and reliability targets. The team implements and tests three firmware approaches with two sampling strategies, measures battery life, latency, and reliability, and evaluates communication performance. Based on the results, the team selects a firmware and sampling approach and refines the communication protocol. Records of the alternatives, test conditions, and results may help support analysis — but professional review is still needed.
Questions to Ask Internally
- What specific business component was being developed or improved?
- What technical uncertainty existed at the outset?
- What alternatives were evaluated, and how were they tested?
- Who performed or directly supported the work?
- What materials were consumed in the testing?
- How does this differ from routine embedded development?
Relationship to the Four-Part Test
The four-part test applies the same way it does in any industry. The work must be directed at developing or improving a business component (permitted purpose), must fundamentally rely on principles of the physical sciences or engineering (technological in nature), must be intended to eliminate a technical uncertainty (elimination of uncertainty), and must be conducted through a structured evaluative process (process of experimentation). Meeting one element is not enough.
Key Takeaway
IoT and embedded systems companies may perform activities that warrant analysis under IRC §41 — particularly work involving firmware, sensor integration, and communication systems. Routine embedded development does not automatically qualify. Professional review is appropriate. For related industries, see our pages on electronics manufacturing and cybersecurity companies.