Why Communication Hardware Projects Run Late: Lead Time, Not Just Alignment

Key Takeaways

• The delay causes on the standard list — unclear requirements, weak cross-functional communication, thin front-end work — are correct for hardware. They were established on physical products before they were established on software. Gupta and Wilemon published on technology-based products in 1990; the Standish CHAOS Report was fielded for 1994. Anyone arguing that this list is a software import has the chronology backwards.
• The problem is not the list. It is that the list draws on one of the four research communities that studied physical product development, and not on the one that measured lead time. Krishnan and Ulrich reviewed roughly 200 papers from 1988 to 1998, explicitly restricted to physical goods, and found the field split into communities that did not talk to each other. One heads its metrics with "project success" and names organizational alignment and team characteristics as its critical success factors. Another heads its metrics with "efficiency", lists lead time among them, and names supplier and material selection and design of production sequence (Krishnan and Ulrich, Management Science 47(1), 2001). The popular list inherited the first, and from the second only project management — which it reads as scheduling discipline rather than as flow control.
• The best-measured delay mechanism in hardware is a queue, not a misunderstanding. In an automotive development program, the administrative lead time of an engineering change ran to several weeks, several months, and in extreme cases over a year, while the actual processing of the change typically did not exceed two weeks (Terwiesch and Loch, Journal of Product Innovation Management 16(2), 1999, DOI 10.1111/1540-5885.1620160). You can fix cross-functional communication completely and not have touched that ratio.
• Component discontinuation runs on a clock set outside your company, and the standard floor is low. JEDEC's discontinuance standard asks for six months' notice to place final orders and twelve months to final shipment. When AMD discontinued nine CPLD and FPGA families on 1 January 2024, it granted 180 and 362 days — two days short of six months and four short of twelve — and in the part tables the replacement column reads "No direct replacement" (AMD, Product Discontinuation Notice XCN23009).
• Three regulatory dates fall between 11 September and 15 November 2026, a span of nine weeks, and all three are verifiable at the register: Cyber Resilience Act reporting obligations on 11 September 2026, the Data Act's product design obligation on 12 September 2026, and the removal of six superseded radio and EMC standard versions from the Official Journal list on 15 November 2026. None of them is negotiable, and none of them appears in any classical delay model.
• One thing this article does not do is tell you what share of your calendar goes to verification and certification, because no one has published a defensible measurement of it. The figure most often quoted in this industry — that roughly half of all products fail their first EMC test — could not be traced to any accredited laboratory, standards body, or peer-reviewed study. Details are in the section on what nobody has measured.

A hardware program slips, someone runs a retrospective, and the findings come back: requirements were unstable, the interfaces between teams were poorly defined, the schedule was optimistic. Those findings are almost always true. They are also almost always insufficient, and the reason is not that the team ran a bad retrospective. It is that the diagnostic vocabulary available to them was assembled by one research community that was never measuring the thing that actually consumed the calendar.

This article is about where the rest of the vocabulary is. Everything below is sourced from primary documents where primary documents exist, and where a widely repeated number could not be traced to one, that is stated rather than papered over. Three such cases appear, and they are among the more useful parts of the piece.

Contents: The causes are right · The other community · The queue · The component clock · Three dates · EN 18031 · What nobody has measured · What is controllable · Checklist · FAQ · Conclusion · Author · Disclosure · Method · Image credits

The causes are right, and they came from hardware

The most common framing error in this discussion is to treat the standard delay list as an artifact of software project management that got bolted onto hardware. It is worth killing that idea early, because it is wrong on the dates and a technical audience will notice.

Gupta and Wilemon surveyed managers developing technology-based products and reported four areas governing development performance: senior management support, early integration of functional expertise, availability and management of resources, and an organizational environment supporting teamwork. That was published in 1990 (California Management Review 32(2)). Cooper and Kleinschmidt examined 103 new product projects in the chemical industry and identified drivers of timeliness led by a cross-functional, dedicated, accountable team with a strong leader, followed by solid predevelopment homework (JPIM 11(5), 1994, DOI 10.1016/0737-6782(94)90028-0). Eisenhardt and Tabrizi studied 72 projects across 36 firms in the global computer industry (Administrative Science Quarterly 40(1), 1995, DOI 10.2307/2393701). Zirger and Hartley studied electronics companies specifically (IEEE Transactions on Engineering Management 43(2), 1996). Griffin measured cycle time across 21 divisions of 11 firms in five industries (Journal of Engineering and Technology Management 14, 1997). Crawford had already argued in 1992 that acceleration carries hidden costs of its own, among them a retreat from learning-intensive innovation and thinner front-end homework (JPIM 9(3), 1992).

Chemicals. Automobiles. Computers. Electronics. These were physical products, and the work predates the Standish CHAOS Report, which was fielded for 1994 and surveyed 365 IT executive managers about 8,380 software applications.

One result from that body of work deserves more attention than it gets, because it sets expectations correctly about how much any of this buys you. Zirger and Hartley tested twelve acceleration techniques against development time in electronics companies. Only four were significantly related to development time as proposed. Faster developers had cross-functional, dedicated teams that treated time to market as an explicit goal and overlapped development activities.

Eight of the twelve, in other words, did not relate to development time in the direction proposed. Whatever governs the rest of an electronics schedule was not on that list, and it is the subject of the rest of this article.

The community nobody inherited from

In 2001, Krishnan and Ulrich published a review of the product development literature in Management Science. They filtered roughly 400 papers down to about 200, covering journals from 1988 to 1998, and stated plainly that they devoted their attention to the development of physical goods. Their Table 1 compares four academic communities working on that literature: marketing, organizations, engineering design, and operations management. Two of those four explain how a correct list of causes can still miss the calendar.

The table starts with what each community takes a product to be. To the organizations community, "A product is an artifact resulting from an organizational process." To the operations management community, "A product is a sequence of development and/or production process steps." Those are not two descriptions of one object. They are descriptions of two different objects, and they generate different questions.

The performance metrics follow. The organizations column heads with "Project success", under it technical performance and innovativeness. The operations column heads with "Efficiency", under it total cost, service level, capacity utilization — and lead time, which appears in that column of the table and in no other.

The critical success factors follow too. For organizations: organizational alignment, team characteristics. For operations management: supplier and material selection, design of production sequence, project management.

The split itself is documented. What follows from it here is inference: nobody suppressed the operations side, but it published in different journals and answered to different reviewers, and we know of no study tracing which of these communities supplied the vocabulary of the industrial project retrospective. The correspondence between the left-hand column and the list in general use is close, and it is offered as that — a correspondence, not a demonstrated lineage.

Set the two lists side by side and the omission is visible without further argument. Everything on the left is about people and their arrangement. On the right, two of the three items are about parts and production sequence; the third, project management, is the one item the popular list did inherit — and it inherited it as scheduling discipline rather than as flow control. A retrospective built from the left-hand list, plus a Gantt chart, can be entirely correct and still never reach a question about a component.

That the operations community was studying calendar time in hardware is not in dispute. Clark and Fujimoto titled their 1989 study "Lead Time in Automobile Product Development: Explaining the Japanese Advantage", and its stated framework tests the effect of product content, project scope and organizational capability on development lead time (Journal of Engineering and Technology Management 6, 1989). Figures on the share of new-part engineering carried by suppliers circulate widely with that paper attached; they are not in the record accessible here and are not repeated.

The queue is the mechanism

If you want a single citation that explains why hardware changes take months when the work takes days, it is Terwiesch and Loch's study of engineering change orders in the climate control system of a vehicle program.

Their finding, reported from the field: the administrative process around an engineering change can take several weeks, several months, and in extreme cases even over a year, while the actual processing time for the change typically does not exceed two weeks (JPIM 16(2), 1999, DOI 10.1111/1540-5885.1620160). They name five contributors, and only one of them is what a retrospective would call a communication problem: a complex approval process, snowballing changes, scarce capacity and congestion, setups and batching, and organizational issues.

Scarce capacity, congestion, setups and batching are queueing terms. They describe a flow problem, and flow problems have flow remedies: pooled capacity, smaller batches, balanced workloads, fewer approval hops. None of those is an alignment workshop, and none of them shows up if the retrospective template only contains the alignment column. The companion paper by the same authors models the effect formally and reports that engineering change orders consume between a third and a half of engineering capacity (Loch and Terwiesch, JPIM 16(2), 1999, DOI 10.1111/1540-5885.1620145).

This is the general shape of hardware delay. What follows are the three specific queues that a communication hardware program sits in, in ascending order of how little control you have over them.

The component clock you do not control

Component discontinuation is the clearest case in hardware of a schedule event that originates entirely outside the project and cannot be accelerated by anything the team does.

The governing document is JEDEC's discontinuance standard, JESD48C. It asks a supplier to give customers six months from notice to place final orders and twelve months from notice to final shipment (JEDEC, JESD48C, clause 3.1). Two properties of that standard matter more than the numbers. It is voluntary, and compliance is unaudited: the document itself states that no claims of conformance may be made unless all requirements are met, but nothing verifies them. And its definition of "customer" covers those who purchased within the past two years under a notification agreement — which can quietly exclude a long-life industrial program that buys in infrequent batches.

Here is what the floor looks like when a supplier settles onto it.

On 1 January 2024, AMD issued discontinuation notice XCN23009 covering nine CPLD and FPGA families, including the XC9500XL and CoolRunner II CPLDs and the Spartan II, Spartan 3, 3A, 3AN, 3E and 3ADSP FPGAs. The stated reason was declining run rate and supplier sustainability. Last time buy was set for 29 June 2024 and last time ship for 28 December 2024. That is 180 and 362 days from notice, against a JEDEC minimum of six and twelve months: two days short at the first gate and four days short at the second. In the part tables of that notice, the replacement part column reads "No direct replacement" (AMD, XCN23009 v1.0).

Around that specific case sits a broader pattern that is worth reporting with its limitations attached. The lifecycle data vendor Z2Data counted 621,909 manufacturer part numbers going end of life during 2025 and reported that 323,286 of them — about 52 percent — carried no product change notification at all (Z2Data, March 2026). That figure comes from a commercial database whose methodology is not disclosed, by a vendor with an interest in the finding, and it counts part numbers rather than design-ins. Treat the exact percentage as indicative. The direction is corroborated by the same vendor's earlier reporting, and the operational implication survives the caveat: the notification mechanism JESD48C describes is not a reliable early warning system.

The supply picture underneath has not returned to anything worth calling normal, and it also is not a crisis. In the Electronic Components Industry Association's February 2026 survey, the share of respondents reporting increasing semiconductor lead times fell from 52 percent in January to 39 percent in February — but only 5 percent reported lead times decreasing (ECIA Industry Pulse, February 2026). Deceleration is not reversal. Underneath the market signal sits a structural floor that no demand condition removes: ECIA puts wafer fabrication at up to twelve weeks and assembly and test at four to eight, within an end-to-end cycle it places at roughly 26 weeks from raw material to finished chip (ECIA, Understanding Semiconductor Lead Times).

The design-side consequence has been measured once, at the peak of the shortage. In a survey of 530 engineers fielded in late 2021, 74 percent reported delayed production schedules, 64 percent said they were designing based on component availability rather than preference, and 55 percent had redesigned a board because a design-in part was unavailable (Avnet Insights, March 2022). That is a non-probability sample drawn from a distributor's own customer list during the worst period on record, and it should be read as an upper bound rather than a current rate. It is also the only quantification of its kind we could find.

For the architectural consequences of designing around availability rather than preference — particularly where a communication processor, an FPGA design, or a soldered module is involved — the trade-offs are set out in our discussion of industrial communication hardware in 2026.

Three dates in nine weeks

The third queue is the one with no negotiation at all, because the counterparty is a legislature. Three obligations relevant to communication hardware take effect between 11 September and 15 November 2026, a span of nine weeks. All three dates below were read from the Official Journal text at the register.

11 September 2026 — Cyber Resilience Act reporting. Regulation (EU) 2024/2847 applies in full from 11 December 2027, but Article 71(2) carves out two earlier dates: "However, Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026" (Regulation (EU) 2024/2847). Article 14 obliges a manufacturer to notify actively exploited vulnerabilities and severe incidents to the coordinating CSIRT and ENISA. Article 69(3) removes the obvious escape route: those obligations apply to products already placed on the market before 11 December 2027. This is not something a 2027 design cycle absorbs. It requires a monitoring and reporting capability to exist by 11 September 2026.

12 September 2026 — Data Act product design. Regulation (EU) 2023/2854 has applied since 12 September 2025, but its central hardware obligation is dated one year later: "The obligation resulting from Article 3(1) shall apply to connected products and the services related to them placed on the market after 12 September 2026." Article 3(1) requires that connected products "shall be designed and manufactured … in such a manner that product data and related service data, including the relevant metadata necessary to interpret and use those data, are, by default, easily, securely, free of charge, in a comprehensive, structured, commonly used and machine-readable format, and, where relevant and technically feasible, directly accessible to the user" (Regulation (EU) 2023/2854). That is a design obligation touching the data model, on-device logging and interface exposure, and it is systematically under-discussed relative to the Cyber Resilience Act.

15 November 2026 — six standard versions lose their citation. Commission Implementing Decision (EU) 2025/893 amends the list of harmonised standards under the Radio Equipment Directive. Its Article 2 states that "Point (2) of the Annex shall apply from 15 November 2026", and point (2) deletes six rows from the list, withdrawing the presumption of conformity from superseded versions including EN 301 893 V2.1.1 for 5 GHz wireless access systems, EN 301 908-3 V13.1.1 and EN 301 908-13 V13.2.1 for IMT equipment, and EN 301 489-52 V1.2.1 for cellular electromagnetic compatibility (Commission Implementing Decision (EU) 2025/893). A project holding radio test reports against a withdrawn version does not have a documentation problem. It has a retest, and retests are booked into someone else's calendar.

The first three rows are the near-term dates; the fourth is the horizon date discussed below. Every date and article reference in this table was read from the instrument's text at the Official Journal on 8 August 2026.

Behind those three sits the date that governs anything being architected now. The Cyber Resilience Act's main obligations apply from 11 December 2027. For a communication hardware program with a two to three year cycle, a product on the drawing board today ships into that regime. And the Act names this audience's products explicitly: Annex III, Class I, item 12 reads "Routers, modems intended for the connection to the internet, and switches", alongside network management systems, physical and virtual network interfaces, and microprocessors, microcontrollers, ASICs and FPGAs with security-related functionalities.

One correction worth making, because it runs the other way: routers, modems and switches are important products under Annex III, not critical products under Annex IV. Annex IV is short — hardware devices with security boxes, smart meter gateways and similar devices for advanced security purposes, and smartcards or similar devices including secure elements. Claiming a higher classification than the Regulation assigns is an error a system architect will catch. Our earlier guide to the Cyber Resilience Act covers the conformity assessment routes in detail.

EN 18031: an onboarding decision that surfaces as a compliance finding

The cybersecurity requirements of the Radio Equipment Directive have been live since 1 August 2025. Delegated Regulation (EU) 2022/30 originally set 1 August 2024, and Delegated Regulation (EU) 2023/2444 replaced that with "It shall apply from 1 August 2025" (Delegated Regulation (EU) 2023/2444). That part is old news.

What still catches projects is the shape of the harmonised standards written to support it. EN 18031-1, -2 and -3 were cited in the Official Journal in January 2025 — but with restrictions, and the restrictions are narrow, specific, and determined by design decisions rather than documentation.

The load-bearing one, from the Annex to Commission Implementing Decision (EU) 2025/138, reads: "This harmonised standard does not confer a presumption of conformity with the essential requirement set out in Article 3(3), first subparagraph, point (d), of Directive 2014/53/EU if, when applying its clauses 6.2.5.1 and 6.2.5.2, the user is allowed not to set and use any password." A second restriction removes the presumption of conformity from every section of the standards named "rationale" and "guidance" (Commission Implementing Decision (EU) 2025/138).

Consider where that decision actually gets made. Whether a device permits an installer to skip setting a password is an onboarding and provisioning decision, taken early, usually by whoever owns the commissioning workflow, and often justified by field service convenience. It is not recorded as a compliance decision. It surfaces as one much later, at the point where the presumption of conformity was supposed to attach and does not.

That is the general pattern this article is about, in its purest form: the same class of error the classical literature identified, discovered late, discovered physically, and remediated through a queue you do not own. What a project can do about it is structural — the product security requirements have to be allocated to architecture before the provisioning flow is fixed, not audited afterwards. The sequence of gates from validation to series release is set out in our article on communication hardware through to series production.

What nobody has measured

This section exists because three numbers that circulate freely in this industry did not survive checking, and saying so is more useful than repeating them.

The share of a hardware program's calendar spent in verification and certification. No source with a disclosed method appears to exist. This is the number that would settle the argument this article is making, and it has never been published. The closest adjacent data point is a benchmark report in which 65 percent of electronics respondents said preparing and submitting certification documentation was growing more complex — a perception measure, not a calendar measure, and drawn from a vendor-sponsored study (Lifecycle Insights, 2021).

The claim that roughly half of all products fail their first EMC test. We could not trace this to any accredited laboratory, standards body, or peer-reviewed study. The trail leads to a vendor white paper from approximately 2007 whose canonical URL no longer resolves, and a third-party review documents that figures of 50 percent, over 90 percent, and 97 percent have all been attributed to the same source without methodology, sample size, or product segmentation (EMI Software review of the claim). That reviewer sells EMC simulation software and would benefit commercially from first-pass failure being common, which makes the direction of its scepticism worth noting rather than discounting. The underlying phenomenon — that first-pass EMC failures are common and expensive — is real and every hardware group has lived it. The number is not evidence.

Second-source qualification duration. No peer-reviewed or association-published measurement was found. The most prominent figure in circulation is attributed to a Semiconductor Industry Association benchmarking study that does not appear to exist: the page carrying it cites only the organisation's name, linked to its homepage, with no study title, date, author, sample or methodology. Related figures on the same page carry the same defect. This is worth flagging precisely because component substitution is now a routine event.

Two further absences are worth naming. There is no published count of notified bodies designated for the Radio Equipment Directive's cybersecurity requirements that we could obtain, because the NANDO database has been migrated into a client-side application that does not expose the query. And there is no methodologically disclosed dataset on accredited laboratory queue times in the EU. Both gaps are frequently filled with confident assertions about bottlenecks. We have none to offer.

What is actually controllable

Three things follow from the evidence above, and they are ordered by leverage.

Treat component longevity as a specification, because vendors publish different ones. Texas Instruments describes typical product life cycles of 10 to 15 years and gives 12 months for a last order plus 6 months for final delivery, an 18-month window it describes as longer than the industry standard (TI, product life cycle and quality FAQs). Microchip states a 12-month window and reports discontinuing roughly 0.2 percent of products annually in 2022 and 2023, with a pledge not to discontinue products having business activity in the past three years, subject to manufacturability (Microchip, product longevity). Those are self-reported and unaudited. They are also a genuine, selectable difference available at design-in, and they are cheaper to choose than to retrofit.

Attack the queue, not the alignment. If Terwiesch and Loch are right that lead time exceeds processing time by an order of magnitude, the highest-leverage schedule intervention in a hardware program is reducing approval hops, batching, and contention for scarce specialists — not another interface workshop. This is measurable inside your own organisation without waiting for anyone to publish a benchmark: instrument the elapsed time and the touch time of your own change orders and compare them.

Forecast from a reference class, not from the plan. Flyvbjerg's work on optimism bias, strategic misrepresentation and reference-class forecasting transfers cleanly as method to a board-level program (Flyvbjerg, Project Management Journal 45(2), 2014). His numbers do not: his unit of analysis is a project costing a billion US dollars or more, and he states in the same paper that megaprojects are "a completely different breed of project" and not merely magnified versions of smaller ones. Use the method, leave the base rates.

One finding deserves a place here because it cuts against a story hardware teams like to tell about themselves. NASA analysed 231 verified hardware errors from a major aircraft program and found requirements-phase errors were the largest single category, at 66 — more than design at 61. The same study measured cost escalation by phase and found hardware running at 1, 8, 16, 21 and 29 times against software comparators of 1, 5 to 7, 10 to 26, 50 to 177 and 100 to 1000, concluding that hardware fixes are more forgiving in cost terms than software fixes (Stecklein et al., NASA JSC / INCOSE, 2004).

Both halves of that are uncomfortable. Requirements quality matters as much in hardware as anywhere, so the alignment column was never wrong. And the familiar 1:10:100 escalation curve, commonly traced to Barry Boehm's Software Engineering Economics (1981) and its analysis of 1970s software projects, overstates late-stage hardware cost. Hardware's problem is not that each fix costs disproportionately more. It is that the clock runs slower and the queue is owned by someone else. For programs where that distinction has to be managed rather than discussed, it is the substance of what hardware development for communication systems has to get right.

Checklist before the next schedule review

• Elapsed time and touch time recorded separately for engineering change orders, so the ratio is visible rather than inferred
• Approval hops per change counted, with an owner for reducing them
• Component longevity commitment recorded per critical part, from the vendor's published program and not from the distributor listing
• Notification agreement in place with each critical supplier, and purchase recency checked against the two-year definition in JESD48C
• Last-time-buy decision authority pre-assigned, with a funded budget line, so a six-month window does not spend two of its months in escalation
• Second source identified for every part whose absence forces a layout change, with the qualification effort estimated even though no published benchmark exists
• Radio test reports checked against the standard versions withdrawn on 15 November 2026
• Article 14 reporting capability of the Cyber Resilience Act operational before 11 September 2026, including for products already in the field
• Data accessibility per Article 3(1) of the Data Act allocated to the architecture for anything placed on the market after 12 September 2026
• Provisioning and onboarding flow checked against the password restriction in the EN 18031 citation before the flow is frozen
• Cyber Resilience Act classification confirmed against Annex III and Annex IV, rather than assumed
• Schedule forecast built from a reference class of your own completed programs, not from the current plan

Frequently asked questions

Is it fair to say the usual delay causes are wrong for hardware?

No, and the article that told you so was wrong. Those causes were established on physical products — chemicals, automobiles, computers, electronics — through the 1990s, and in the key case the hardware publication predates the software one by four years. NASA's error analysis puts requirements errors first by count even in a pure hardware program. The defensible claim is narrower: the popular list draws on the research community that measured project success through organizational alignment, and not on the community that measured lead time through supplier and material selection and production sequence.

What is the single highest-leverage change to a hardware schedule?

On the available evidence, reducing waiting time in the engineering change process. Terwiesch and Loch found administrative lead times running from several weeks to over a year against processing times of two weeks or less. No other reported mechanism in the hardware literature shows a gap of that size, and it is one of the few that a company can measure and act on without external cooperation.

Does the Cyber Resilience Act apply to a product we ship before December 2027?

Partly, and this is the trap. The main obligations apply from 11 December 2027 and products placed on the market before then are only caught if they undergo a substantial modification after that date. But Article 69(3) makes the Article 14 reporting obligations apply to products already placed on the market, and Article 14 itself starts on 11 September 2026. Reporting duties for actively exploited vulnerabilities are therefore not deferrable to your next design cycle.

Do we need a notified body for the RED cybersecurity requirements?

That depends on whether your design falls inside one of the restricted clauses in the Official Journal citation of EN 18031. Where the harmonised standard is applied in full and no restriction bites, the presumption of conformity attaches. Where a restriction applies — the password case is the common one — the presumption does not attach for that requirement and conformity has to be demonstrated by another route. We are not able to tell you how much notified body capacity exists for this, because no count is obtainable from the register since the NANDO migration.

How long does it take to qualify a second source?

Nobody has published a defensible answer. We searched for peer-reviewed, association-published and standards-body data and found none, and the most-cited figure in circulation is attributed to a study that does not appear to exist. Estimate it from your own qualification history and treat any external number you are shown as unsourced until its methodology is produced.

Are component lead times back to normal in 2026?

Not on the most recent primary data we could verify, and not structurally either. In February 2026 the share of respondents reporting increasing semiconductor lead times had fallen to 39 percent from 52 percent a month earlier, but only 5 percent reported decreases. Beneath any market condition sits a fabrication-to-shelf cycle of roughly 26 weeks that no demand environment shortens.

Conclusion

The retrospective that says your hardware program slipped because requirements were unstable and teams were misaligned is not wrong. It is drawing on real research that was conducted on real hardware. It is simply working from one of the four research communities Krishnan and Ulrich identify, and communication hardware spends its calendar in the concerns of another — in supplier and material selection, in production sequence, in the queues that convert two weeks of work into six months of elapsed time.

The practical consequence is a change of target. Cost per fix escalates less steeply in hardware than the borrowed software curve suggests, so chasing defect-cost avoidance has less leverage than it appears. Elapsed time is where the losses are, and most of it is waiting rather than working. Three of those waiting periods already have dates attached: 11 September, 12 September and 15 November 2026. Those are the ones you can plan around today. The rest — the discontinuation notice that has not been issued yet, the retest slot that has not been booked — you plan for by building slack where the clock is owned by someone else, and by measuring your own queues before someone else's queue measures you.

Disclosure

Teleconnect develops and manufactures communication hardware commercially and has a direct commercial interest in the subject matter of this article, including in hardware, firmware and PCB design services referenced above. The article names no product of ours as a remedy for any finding.

Teleconnect is a member of the HomeGrid Forum. Two employees of our company jointly chair its industrial IoT task force. This membership has no bearing on the standards and regulations assessed here, none of which is administered by that forum.

The regulatory dates in this article concern obligations that apply to our own products as much as to our customers'. Where this article reports that a figure could not be verified, that finding is stated without regard to whether a verified figure would have supported our commercial position.

Method and sources

All European legal facts were read from the text of the instrument at the Official Journal, retrieved 8 and 9 August 2026. EUR-Lex answers automated requests with an HTTP 202 challenge, so the pages were loaded with a real browser engine and the operative articles transcribed from the rendered text. The instruments are: Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 71(2) for the application dates, Article 69 for the transitional provisions, and Annexes III and IV for the product classes; Regulation (EU) 2023/2854 (Data Act), Article 3(1) for the design obligation and the final article for its application date; Commission Delegated Regulation (EU) 2022/30 and Commission Delegated Regulation (EU) 2023/2444 for the Radio Equipment Directive cybersecurity application date; Commission Implementing Decision (EU) 2025/138 for the EN 18031 citation and its restrictions, quoted from the Annex; and Commission Implementing Decision (EU) 2025/893, Article 2 and Annex point (2), for the standard withdrawals effective 15 November 2026.

The product development literature is cited from the published record. Where only an abstract or a secondary description was available rather than the full text, no verbatim quotation is given and the claim is stated at the level the accessible source supports. This applies to Cooper and Kleinschmidt (1994), Gupta and Wilemon (1990), Crawford (1992), Zirger and Hartley (1996), Griffin (1997) and Clark and Fujimoto (1989). No ranked list of delay causes is attributed to Gupta and Wilemon, because that table could not be obtained, and no variance-explained statistic is attributed to Zirger and Hartley for the same reason, only the count of techniques their abstract reports as significant. Krishnan and Ulrich (2001) was read directly from the author-hosted PDF for the passage and the table cited, including the row labels, the four community names, and the quoted contents of the Perspective on Product, Typical Performance Metrics and Critical Success Factors rows, all transcribed from Table 1 rather than summarised. The statement that lead time appears in one column of that table and in no other is a reading of all four columns. The Standish CHAOS Report is described by its scope and sampling only; its figures are not used, for reasons documented in the peer-reviewed criticism of it by Eveleens and Verhoef (IEEE Software 27(1), 2010) and Jørgensen and Moløkken-Østvold (Information and Software Technology 48(4), 2006).

Manufacturer facts come from the manufacturer's own document rather than from a distributor's product listing or a third-party summary of it: AMD notice XCN23009 v1.0, JEDEC JESD48C, and the published longevity programs of Texas Instruments and Microchip. Two of those originals are served from a host other than the issuer, the AMD notice from a distributor's document server and JESD48C from a semiconductor manufacturer's public library. The document in each case is the issuer's own unaltered PDF, which is the distinction drawn here; a paraphrase hosted by a third party would not qualify, which is why the NXP longevity figures are omitted below. Vendor statements about their own practice are identified as such and are unaudited. Two sources carry disclosed commercial interest and are labelled where used: the Z2Data obsolescence counts, whose methodology is not published, and the Lifecycle Insights benchmark report, which is vendor-sponsored. The Avnet survey is a non-probability sample from a distributor's customer list taken at the peak of the 2021 shortage.

Not verifiable and therefore not used: any first-pass EMC failure rate; any measurement of the share of a hardware program's calendar consumed by verification and certification; any duration for second-source qualification; any count of notified bodies designated for the Radio Equipment Directive cybersecurity requirements; any accredited laboratory queue time. A figure of 2.9 board respins at 44,000 US dollars each circulates widely and could not be reconciled with the primary benchmark report it is attributed to, which reports different quantities entirely; it is not used. Shares of new-part engineering carried by suppliers in Japan, Europe and the United States are frequently attributed to Clark and Fujimoto (1989); the record accessible here does not contain them, and they are not used either. The application date of the Machinery Regulation (EU) 2023/1230 is subject to an unresolved discrepancy between the original Official Journal text and the dates reported after its 2023 corrigendum, and since that Regulation does not govern communication hardware as such, it is omitted rather than stated uncertainly. NXP's product longevity commitments were found only on a third-party mirror during preparation and are therefore not cited, although the program is understood to be current.