Contact Us

FAQs

These are the questions we get asked most often by the people we work with, grouped by topic so you can skip to what matters.

If yours isn’t here, get in touch it probably has more nuanced answer rather than a tidy one.

1. Working with Ignys

First, we need to understand what your end goal is. What’s important to you? What problem are you solving? This gets captured in a Product Requirement Spec where every requirement is measurable and uniquely numbered, then used through development and verification so nothing is missed and performance requirements are checked. “Pretty” and “light” aren’t quantifiable or measurable, so they aren’t definitive requirements.

The more subjective a requirement is, the more room for divergence between the specifier and the design team; resolving that needs guided iterations to optimise the trade-offs.

We work through six defined stages from Specification to Field Trial Prototype, each with clear inputs, deliverables and decision points. This means you always know where the project is, what the next milestone delivers and what it costs. It also means we can engage at the right stage if you already have work in progress, rather than starting from zero.

It depends on complexity and scope, so anyone giving you a single number without asking questions is guessing. As a rough guide, a focused feasibility study is four to six weeks; a full hardware and firmware development from specification to field trial prototype is typically six to nine months for a moderately complex product. Compliance testing, tooling and production setup add to that. We give you a phased plan with realistic dates rather than an optimistic single figure nobody believes.

They usually do, and that’s why we use a numbered, measurable Product Requirement Spec. When something needs to change we assess the impact on cost, timeline and other requirements before we touch anything, then we tell you. You stay in control of the trade-offs rather than discovering them at the end.

Schematics, PCB layouts, gerbers, bills of materials, firmware source, test reports, design rationale and review records. The IP belongs to you, and so does the reasoning behind it, which means your team or a future supplier can pick the design up without guessing why a decision was made.

It starts at the specification by making requirements testable. During development we use peer review, structured verification and stage gates to catch issues while they’re still cheap to fix. We also flag commercial risks alongside technical ones: component lead times, single-source parts, regulatory uncertainty, assumptions about volume. You see the risk register, not just the happy path.

You might be. Building a team from scratch is a big undertaking. Recruitment takes more energy, effort and time than it should, and the associated costs can be significant. You’ll need equipment, licences for CAD tools, processes that work, and someone to manage the team (don’t let engineers just wander off on their own). If electronics and firmware isn’t your personal area of expertise, how will you know if the interviewees are competent and capable?

Do you have a funded and approved roadmap of products to launch, or is the engineering demand likely to come in bursts? You may create a product and then switch focus to sales and marketing to drive revenue. At that point you have an engineering overhead you’re keeping busy but which isn’t necessarily doing purposeful, commercially focussed work.

You do. The design files, source code, documentation and rationale we produce on your project belong to you. We retain rights only to background IP we bring with us, such as our internal libraries and reusable building blocks, which we license into your product.

NDAs are standard at the first substantive conversation. Project information is handled on a need-to-know basis internally. We don’t publish case studies or use logos without written sign off. If you have a direct competitor in our existing client base, we’ll tell you before we engage.

Established SMEs adding to a product range, larger organisations needing specialist input or extra capacity, and funded start-ups. The common factor is genuine commercial intent, not company size.

2. Our Approach to Engineering and Design

When you’ve looked at something for a while it can be really hard to see problems with it. You’re so familiar with the circuit, approach, code or report that finding errors is nearly impossible. Getting another competent engineer to look over the design ensures assumptions get challenged, implementations get checked, and the overall output is better. For hardware, this saves on PCB prototyping spins, keeping timelines tight and avoiding wasted money on low-quality prototypes. It also helps preserve components when supply chains are challenging or there are only a handful of parts available.

No two designs are the same, but a few factors consistently affect review time. The least surprising is design complexity: number of interfaces, pin counts, speed, layer stack. Other factors include the quality of the specification, the schematic drafting clarity, and the output of CAD tools such as gerber files and bills of materials. If your schematic is well-drawn, includes the necessary information, the bill of materials identifies components definitively, and there’s a specification to check the design implementation against, we spend less time clarifying and more time verifying that your implementation is likely to meet the requirements.

Electronics design is complex. We’re integrating multiple companies’ intellectual property components into a design. Sometimes these are being used for the first time and we have to rely on the completeness of their datasheets and applications guides; other times we’ve used the devices multiple times already in different applications. There are also human fallibility factors. Thorough specifications, robust repeatable processes, experienced engineers and peer reviews prevent most issues, but it would be hubris to assume there’s never the need for a re-spin.

Most products also interact with enclosures, and while modern CAD tools are pretty good, there’s no substitute for using the prototype itself and seeing that the buttons should be further apart, or that the interface is awkward to use.

When complexity increases further we may even cater for the assumption of a “C-model” unit, but this is rare. A red flag we look out for is when an enquirer has already spun their PCB a number of times but is still tweaking, adjusting and possibly guessing.

Yes, and we think doing both in the same team matters. Most awkward product issues live at the boundary between hardware and firmware, and that boundary is where things fall through the cracks if the two are split across separate suppliers. We cover bare metal and RTOS targets, drivers, communication stacks and application layer.

Yes. Battery life is mostly decided by architectural choices made before anyone writes a line of code: microcontroller selection, sleep strategy, peripheral power management, how often the product talks to the outside world. We size the energy budget against the real application early, so you don’t end up with a product that only hits its claimed battery life on a lab bench.

Yes. Multi-layer stack-ups, controlled impedance, DDR memory, gigabit interfaces and mixed-signal layouts are routine. Where complexity warrants it we run signal integrity simulation rather than trusting rules of thumb.

We work across BLE, Wi-Fi, LoRaWAN, cellular and sub-GHz. Choice of radio is as much a commercial decision as a technical one, balancing range, power, data volume and certification cost, so we work that through with you rather than defaulting to whatever’s in fashion.

Probably, but tell us. We work across the major microcontroller, sensor and connectivity ecosystems. If you’ve already chosen a part we’ll tell you whether the choice is sensible before we start. If you haven’t, we’ll help you make the call rather than presenting it as fait accompli.

Tell us your sector and we’ll be straight about which standards we have direct experience with. Where a project needs a standard we haven’t worked to before, we’ll say so and bring in the right specialist input rather than learning on your money.

3. Compliance and Certification

Yes. We design with the relevant directives in mind from the schematic stage, including EMC, the Low Voltage Directive, RED for radio products, RoHS and others depending on application. We coordinate pre-compliance and full compliance testing with accredited labs, and we put together the technical documentation pack you need for the Declaration of Conformity.

The CRA applies to almost any product with digital elements placed on the EU market. Reporting obligations apply from 11 September 2026 and the substantive obligations apply in full from 11 December 2027. We design products with secure boot, secure update, vulnerability handling and the documentation trail the CRA requires. If you already have a product on the market we can run a gap analysis and tell you what needs to change. There’s a fuller section on the CRA and EN 18031 further down this page.

Wireless products need RED in Europe, FCC in the US and carrier certification if you’re using cellular. We factor this in from the schematic, plan antenna placement during PCB layout, and build the certification route into the project timeline rather than treating it as a surprise at the end.

4. After Launch and in Production

Yes. Components go obsolete, regulations evolve, customers find edge cases, and at some point you’ll want a v2. We retain the design knowledge from your project and can engage on a retainer or as-needed basis depending on the product’s lifecycle.

Regularly, yes. We run a design review, identify root cause on field failures, and take the design forward to a stable revision. Tell us what you have, what’s going wrong and how many units are affected. The sooner we see it, the cheaper the fix tends to be.

Yes. Cost reduction work covers component substitution, redesign for manufacture, alternative sourcing, test optimisation and yield improvements. We aim for a clear payback: the project cost should be recovered through unit savings within a defined production volume.

We work with your manufacturer or recommend one from our network. Handover includes the full manufacturing pack, test specifications, programming and calibration procedures, and a first article support phase. We don’t disappear the moment the design is signed off.

Where the risk is foreseeable, we design with second sources or pin-compatible alternatives in mind. Where obsolescence hits a product already in production we run a focused redesign on the affected area, validate the replacement, and minimise disruption. If specific parts are worrying you, we can run an obsolescence risk review on your existing design before it becomes urgent.

5. Cybersecurity: RED Article 3.3, EN 18031 and the Cyber Resilience Act

RED is the Radio Equipment Directive 2014/53/EU. Article 3.3 sets essential requirements that radio equipment must meet to carry the CE mark, including the cybersecurity sub clauses (d), (e) and (f). These were activated by Delegated Regulation 2022/30. Since 1 August 2025, products placed on the EU market that fall in scope must demonstrate they meet these cybersecurity requirements.

1 August 2025. Products placed on the EU market on or after that date must comply. The harmonised standard giving presumption of conformity, EN 18031, was published in the Official Journal of the EU on 30 January 2025.

Article 3.3(d) catches any radio equipment that can communicate over the internet, directly or via another device. Article 3.3(e) catches radio equipment that processes personal data, including wearables and connected toys. Article 3.3(f) catches radio equipment used for financial transactions. In practical terms, connected industrial sensors, alarm panels with cellular or BLE backhaul, smart meters, wearables that sync to a phone app, asset trackers and consumer IoT devices all fall in scope.

Almost certainly yes. The legal trigger is whether the radio can communicate over the internet directly or indirectly. A BLE-only product that pairs with a phone app and uploads data to a cloud service is communicating over the internet indirectly. The same applies to a sub-GHz sensor that talks to a gateway that talks to the cloud. The radio interface itself doesn’t have to be IP capable for Article 3.3 to bite.

EN 18031 is the harmonised standard series that gives presumption of conformity with RED Article 3.3. It’s in three parts. EN 18031-1 covers network protection (Article 3.3(d)). EN 18031-2 covers privacy and personal data (Article 3.3(e)). EN 18031-3 covers financial transactions (Article 3.3(f)). In engineering terms the requirements cover authenticated access (no default passwords, no skippable authentication), encrypted communication, signed firmware update with rollback protection, input validation, security event logging, resilience against denial of service, and a documented security risk assessment. Each requirement maps to a code (ACM, AUM, CCK, SUM and others) that you assess against your product’s functions.

Most internet-connected products need to meet EN 18031-1. If your product processes personal data, sends health or location information, or is intended for or attractive to children, you also need EN 18031-2. If your product handles payments or other monetary transactions, you also need EN 18031-3. The three parts overlap heavily; 28 of the requirement codes are common across all three, but the specific text and applicability differ enough that each part needs to be checked separately.

You can self-declare against EN 18031 provided no “restricted clauses” apply to your product. The harmonised standards published in January 2025 came with specific restrictions. If your product hits one of them, the harmonised standard alone doesn’t give presumption of conformity and notified body involvement becomes mandatory. Common triggers include products where users can skip setting a password, certain childcare device authentication scenarios, and secure update mechanisms for financial transaction devices. For most general industrial and consumer IoT products, self-declaration is the route.

Different scope and different timing. RED Article 3.3 applies only to radio equipment and is mandatory now. The Cyber Resilience Act applies to almost any product with digital elements regardless of whether it has a radio, with incident reporting obligations from 11 September 2026 and full obligations from 11 December 2027. The technical expectations overlap heavily (secure development, vulnerability handling, signed updates, software bill of materials) but the legal frameworks are separate. Products that fall under both must satisfy both.

Products genuinely placed on the EU market before that date aren’t retroactively subject to RED Article 3.3. However, a security-relevant update or significant functional change after 1 August 2025 can cause the product to be treated as newly placed on the market, triggering reassessment. This catches more manufacturers than expected: a routine cloud platform update, a new feature, or a refreshed app can be enough.

The UK Product Security and Telecommunications Infrastructure Act has been in force since 29 April 2024 and applies to consumer connectable products sold into the UK. Its requirements (no default passwords, declared minimum security update period, vulnerability disclosure policy) overlap with EN 18031, but the documentation and scope are different. If you sell into both UK and EU, you need to satisfy both. A product designed properly for EN 18031 will generally meet PSTI’s technical expectations, but the documentation packs are separate exercises.

IEC 62443 is the international cybersecurity standard for industrial automation and control systems. It’s not harmonised under RED, so it doesn’t give an automatic presumption of conformity. You can use IEC 62443 as your technical foundation and write a justification showing it meets the RED Article 3.3 essential requirements, but that route requires a notified body and more documentation work than going via EN 18031. For most products, EN 18031 is the simpler path. For complex industrial systems where IEC 62443 is already in use, the bridging approach can be efficient.

You can’t legally place it on the EU market. National enforcement authorities can require withdrawal of non-compliant products from sale, impose fines, and require corrective action. Distributors and large industrial customers are also actively asking for evidence of compliance before they’ll list or buy a product. In practice, non-compliance becomes a commercial blocker before it becomes a legal one.

Secure boot is a process where the microcontroller verifies the cryptographic signature of the firmware before executing it. It prevents an attacker from running modified or malicious firmware on your device. You don’t strictly need it for every product, but for any product subject to EN 18031 it’s the cleanest way to satisfy several requirements at once: integrity protection, anti-rollback, and the chain of trust that secure update relies on. Most modern microcontrollers support secure boot in hardware; using it well is more about implementation discipline than added cost.

Secure update is a mechanism that lets you legitimately update firmware in the field while preventing an attacker from doing the same. The minimum is cryptographic signing of firmware images, version anti-rollback, and authenticated delivery. EN 18031 expects this. The CRA goes further and expects coordinated vulnerability disclosure, defined security update support periods, and the ability to push security fixes to deployed devices. A product with no field update path is effectively non-compliant for any meaningful service life.

A software bill of materials (SBOM) is a structured list of every software component in your firmware: open source libraries, RTOS components, vendor stacks, with versions. The CRA expects manufacturers to maintain one and to use it to identify and respond to vulnerabilities affecting components in their products. Without an SBOM you can’t credibly claim to handle vulnerabilities, because you don’t know what’s in your own product.

The pattern is consistent across sectors: hard-coded credentials in firmware, default passwords that users can skip changing, unsigned firmware updates that can be rolled back to known vulnerable versions, debug interfaces (UART, JTAG, SWD) left open in production units, communication encrypted at the transport layer but with no certificate validation, and an absence of any software bill of materials. None of these are technically hard to fix. They exist because cybersecurity wasn’t in the original design brief.

Specification stage. Cybersecurity is an architectural decision, not a feature you bolt on at the end. The choices made in the first weeks of a project (microcontroller selection, whether to use a secure element, communication stack, update mechanism, manufacturing provisioning) determine what compliance options exist later. Retrofitting cybersecurity to a finished design is expensive, slow, and often forces a hardware re-spin. Ignys builds the security architecture into the Specification stage of our six-stage process so the rest of the design follows from it.

Yes. We design hardware and firmware with EN 18031 requirements built in from specification stage: secure boot using the silicon’s hardware root of trust, signed firmware update with rollback protection, authenticated and validated communication, no default credentials in production builds, debug interface lockdown, and a documented security risk assessment to support self-declaration. Ignys has won the ELEKTRA Award for Electronics Design Team of the Year three years in succession, in part for this kind of disciplined process work.

Yes, regularly. We run a structured gap analysis against EN 18031 (and the CRA where relevant), identify the changes needed, and scope a remediation route. Sometimes the fix is firmware only, sometimes it’s a hardware re-spin, and occasionally the most economical answer is a redesign. We tell you straight which it is and what it costs before any further work starts.

Still have questions?

If your question isn’t covered above, get in touch. A short conversation is usually faster than guessing whether we’re the right fit for your problem.

Contact us today