NON-PAPER
This paper is distributed solely for discussion purposes. It reflects an independent analytical perspective and is not presented on behalf of any organization, body, or regulatory authority.
1. Setting the Context
The convergence of the EU Cyber Resilience Act, NIS2, DORA, and national implementations such as BSI TR-02102 creates a compliance landscape for which many organizations with long-standing embedded product lines are structurally unprepared - not due to a lack of technical solutions, but due to a lack of a common approach that integrates technical capability, budgetary autonomy, and risk appetite into a single, actionable timeline.
This is not a failure of any single function, company, or industry. It is the predictable result of three decades of technological decisions, each made under different circumstances, that are now converging on a regulatory deadline that does not distinguish between historical legacy issues and current negligence. Treating this convergence as a blame game is counterproductive: it encourages concealment over disclosure and inaction over incremental progress.
2. Diagnosis, Without Blame
Three institutional patterns recur across organizations, regardless of industry or size:
- Technical knowledge of exposure (legacy silicon without cryptographic isolation, insufficient memory for PQC migration, lack of side-channel protection) typically exists long before action is taken - the gap lies in decision-making authority and funding, not in awareness.
- Risk-averse institutional behavior, when acting rationally within the framework of its own incentives, tends to discourage disclosure rather than facilitate remediation, since disclosure without a funded remediation plan creates risk without offering corresponding risk mitigation.
- Capital allocation processes designed for predictable, limited costs receive compliance issues reported either as “resolved” (which underestimates the residual risk) or as “critical” (without actionable cost or time estimates) - both of which are poor bases for decision-making.
The result is a structural stalemate: Each pattern is rational in and of itself, and the overall result is stagnation.
3. The Manufacturing Dimension: Disruption as Capital Destruction
For manufacturing companies - particularly in the Industry 4.0 context, where product lines are tied to long depreciation cycles, specialized supply chains, and capital-intensive tooling - this stalemate takes on a specific and more acute form.
The prevailing vocabulary surrounding compliance-driven technological change draws heavily on the term “disruption” - a term that became popular to describe market entry, not asset management. When applied to an existing inventory of manufacturing equipment or industrial products in the field, disruption is not a neutral or even positive event:
It is the forced write-off of capital that has not yet reached its intended useful life. A product discontinuation triggered by the inability to meet a cryptographic compliance deadline is not innovation - it is the destruction of prior investments, often exacerbated by the costs of a rushed replacement cycle carried out without the lead time such transitions typically require.
This distinction is important because it changes the nature of the decision facing manufacturing companies. The choice is not “innovate or stagnate” - the framing suggested by the rhetoric of disruption - but rather “consciously shape a forced transition, or have it imposed at the moment of regulatory or market-driven failure.” Paranoia in the face of a real, credible risk of discontinuation is not an overreaction; it is an accurate assessment of the situation. What is missing is not risk awareness, but a path that treats the transition as a managed capital process rather than a binary cliff edge.
This is precisely where interim, verifiable technical measures - border protection approaches that extend the compliance-compliant service life of existing hardware without a complete redesign - play their true role: not as a permanent substitute for modernization, but as a deliberate deceleration of an otherwise forced, value-destroying disruption into a planned, capital-preserving transition.
One caveat is in order here: The characterization of the technical solution as “a coprocessor solves it” is itself a simplification that this paper does not wish to accept unquestioningly. A hardware-based protective measure eliminates the cryptographic exposure of the affected module. It does not resolve legacy issues - expiring certificate trust chains, firmware update infrastructure built for the old architecture, or other non-cryptographic obsolescence within the same product generation - and it does not, by itself, answer the question of who bears the resulting costs. The following case study is deliberately expanded to highlight these gaps, rather than presenting the technical solution as a complete resolution.
There is another dimension that pure cost accounting does not capture: customer inertia is not an obstacle to be overcome, but rather the actual value being purchased. An OEM customer who selects a component supplier is, to a large extent, purchasing the ability to not have to rearchitect their own system according to the supplier’s schedule. A corrective measure that forces the customer into cascading requalification, redesign, or downtime not only costs money - it breaks the specific promise upon which the original purchase decision was based. From the customer’s perspective, a technically correct solution that forces the customer to disrupt its own operations in order to remain compliant is indistinguishable from the end-of-life that it was actually intended to prevent. To put it plainly, the design goal is not “compliant” - but rather “compliant without forcing the customer to take action.”
4. A Forward-Looking Framework
Breaking the stalemate described in Section 2 - and avoiding the destructive dynamic described in Section 3 - requires treating technical remediation, disclosure practices, and capital planning as a single coordinated timeline, rather than as sequential hand-offs in which each side waits for clarity from the other.
A workable approach relies on three parallel, mutually reinforcing lines of action:
- Technical: Creating an inventory against a minimum crypto-agility baseline (dedicated signing hardware, side-channel protection class, PQC-compatible memory headroom). Where a complete redesign within the remaining product lifecycle cannot be economically justified, implementation of interim protective measures - explicitly documented as interim, not presented as a permanent architecture, and, wherever possible, limited to drop-in compatibility with the existing customer interface.
- Disclosure Policy: A documented, dated, and funded remediation plan is treated as the primary risk-mitigation measure, since, according to most current regulatory interpretations, a credible remediation timeline reduces risk more effectively than silence.
- Capital Planning: Replacing binary “resolved/critical” reporting with milestone-based reporting - staggered budget release tied to demonstrated technical progress, rather than full upfront allocation or withholding funds until complete certainty is achieved.
5. Hard Milestones (illustrative, 24-month horizon)
| Time Period | Technical Milestone | Disclosure Milestone | Funding Milestone |
|---|---|---|---|
| Months 1–6 | Assessment & risk classification completed | Framework for remediation disclosure established | Base funding released |
| Months 7–12 | Interim safeguards implemented on highest-risk lines | First remediation plan documented | Milestone-linked funding, Tranche 2 |
| Months 13–18 | PQC migration piloted for new developments | Proactive regulatory engagement, where applicable | Funding Tranche 3, linked to pilot results |
| Months 19–24 | Crypto agility baseline achieved for prioritized product lines | Compliance status documented for audit | Transition to standard budgeting |
6. Concluding Remarks
This framework does not resolve the underlying tension between historical underinvestment and current regulatory deadlines - no framework can retroactively fund three decades of deferred maintenance. What it offers is a way to channel this tension into a limited, controllable, capital-preserving process, rather than an unlimited, value-destroying one. The alternative to a structured path is not the absence of costs - it is the same costs, incurred later, under worse conditions, framed as disruption rather than managed as a transition.
APPENDIX - Illustrative Case Study
The following narrative is fictional and composite. It does not describe a real company, and no resemblance to any named or identifiable organization is intended. It serves to concretely illustrate the framework of this paper, not to report on an actual transformation.
Case: A fictional medium-sized industrial company (“Vantric Industrietechnik GmbH & Co. KG”)
Vantric is a fictional, family-run manufacturer of industrial control and automation components - the kind of high-end medium-sized business commonly found in the German industrial landscape:
approximately 1,400 employees, three generations of family ownership, and a product portfolio consisting of connectivity modules, sensor gateways, and PLC peripherals with typical field lifespans of 12–18 years. Revenue is solid, but margins are thin in a highly competitive OEM supply market. The company is neither large enough to absorb a compliance shock unnoticed nor small enough to escape the regulatory scope.
Month 0 - The Trigger
The trigger was not a security incident. It was a procurement questionnaire from a customer - a Tier-1 automotive supplier - that required, as a standard attachment to the request for proposal, a documented PQC migration roadmap and a CRA declaration of conformity for a gateway module that Vantric had been shipping largely unchanged since 2014. The engineering manager in charge was unable to answer the questionnaire. As it turned out, no one in the entire company could.
Months 1–4 - The Stalemate, Exactly as Predicted
The pattern described in Section 2 of this paper played out almost exactly as described. The head of embedded development, Mr. K., had already pointed out the lack of hardware-isolated key storage in the underlying silicon base two years earlier in an internal memo - filed away, acknowledged, but not funded. Upon reviewing the request for proposals, the legal department recommended not disclosing the gap until “further internal review,” out of concern that any written admission could become evidence in a future liability case. The CFO, faced with a cost estimate that ranged from “manageable” to “existentially threatening” depending on whether a complete redesign or an interim measure was assumed, postponed the decision until the next fiscal quarter - a pattern of delay that the finance team recognized from two earlier, unrelated compliance cycles.
Mr. K. considered resigning. He didn’t, but the internal blame game - “who allowed this to happen?” - consumed most of a quarter that was actually supposed to be devoted to remediation.
Month 5 - The Reframing
What changed was not new information - it was a reframing introduced by an external consultant who had originally been brought in for an independent GDPR matter. He pointed out that the company’s own product lifecycle data (average field service life: 14 years) meant that a complete portfolio redesign was neither necessary nor economically viable for the majority of the affected product line.
About 60% of the units shipped still had a projected remaining service life of 4–7 years - long enough that an interim protective measure (a small, security-hardened coprocessor, to be added during the next scheduled hardware revision) would keep them compliant until the end of their natural life. The remaining 40%, concentrated in newer product lines with a remaining lifespan of over 10 years, did indeed warrant a redesign - but at the normal development pace, not in a panic.
This reframing achieved two things at once: It gave the legal department a defensible, documented position (“a funded, dated remediation plan, differentiated by product cohort”), and it gave the CFO a specific number rather than a range anchored in “existential threat.”
Months 6–18 - Implementation, with Friction
The rollout did not go smoothly. A supplier of the proposed coprocessor experienced a six-week supply bottleneck, which pushed the Q3 milestone back to Q4. A product manager whose bonus was tied to a now-delayed product refresh - unrelated to compliance work - advocated - unsuccessfully - for downgrading the coprocessor development in favor of his roadmap. The works council raised valid questions about whether the interim measure constituted a permanent downgrade in build quality, which required two additional weeks of technical briefings to clarify the matter.
None of this derailed the plan. It delayed it by about one quarter compared to the original 24-month timeline - which the steering committee had deliberately factored in as a buffer from the outset by budgeting 27 months instead of 24, precisely for this reason.
Months 12–20 - Costs Don’t Disappear; They Just Shift
The coprocessor solved the cryptographic capacity issue for the affected gateway module. It did not, however, solve two other problems that arose almost immediately once the solution reached the commercial side of the business.
First, the additional cost increase of €1.85 per unit could not, in practice, be absorbed across the entire customer base - low-margin OEM contracts with multi-year fixed-price commitments meant that the increase either had to be absorbed (which further eroded the already tight margin) or passed on through contract renegotiation. The sales management, faced with the prospect of having to renegotiate fixed-price agreements with several long-standing customers in the middle of their contract terms, openly resisted: The internal argument was not that the solution was wrong, but that “no one sells a security feature that no one asked for at a price premium that no one budgeted for.”
When the price pass-through was announced, two smaller customers demanded competing new quotes instead of simply accepting the increase - one ultimately stayed, citing the documented remediation plan itself as a differentiating factor; the other did not stay and was lost to a competitor who continued to deliver the unupgraded legacy design.
Second, and less visible internally, the solution generated costs on the customer side that Vantrics’ sales team had not originally factored into the discussion. Customers who operated the affected gateways as embedded components of their own certified systems faced their own recertification costs - renewed conformity assessments, in some cases recertification of downstream products that contained the Vantrics module as a subassembly, as well as planning for field retrofits with associated downtime. For customers in regulated industrial environments, this was no trivial burden to pass on; several requested extended transition periods, and one asked directly, “Who’s going to finance this on our end?” - a question to which Vantrics’ sales team had no prepared answer.
The solution, developed over about two additional months of commercial and technical negotiations, was shaped by a requirement that the customer support team had insisted on from the very beginning: Whatever solution was chosen, it had to be drop-in compatible with the form factor, pinout, and firmware interface of the existing gateway. The customers’ own certified systems had been built and certified around Vantrics’ original module; anything that would have forced the customer to modify its own architecture - a new mechanical footprint, a changed communication protocol, a firmware API break - would have shifted the costs from “a single item” to “an entire program” and triggered precisely the kind of cascading re-certification on the customer’s side that no price negotiation could have offset. An early technical proposal - a more powerful but pin-incompatible replacement module - was rejected for this reason alone, even though it would have been cheaper per unit than the coprocessor approach that was ultimately delivered.
The chosen solution - the coprocessor, added during the next scheduled hardware revision - adhered to this requirement precisely because it operated behind the existing interface: from the customer system’s perspective, nothing changed except for a compliance certificate. That was what made the financing discussions with the bank and the tiered pricing with customers viable in the first place - the underlying business case presented to every stakeholder, both internal and external, boiled down to the same sentence: Your operations do not need to change for this to be resolved. Vantric’s existing primary bank agreed to extend the company’s investment credit line specifically against the documented, milestone-based remediation plan - the same plan that had addressed the legal department’s disclosure concerns became the basis for the loan, as it offered the bank a limited, time-bound risk rather than an open-ended one. For the largest affected customers, an optional extended service contract was offered that bundled the hardware update with integration support from Vantric, thereby transforming a pure cost pass-through into a service offering with its own margin. The pricing itself was phased in over the remainder of the contract term rather than applied immediately.
Where the statement “Your operations do not need to change” did not apply - in the case of the discontinued third-party wireless module mentioned below, for which there was no drop-in equivalent - the company was honest that genuine disruption with real cascading costs on the customer side was unavoidable, and treated it as a separate, slower-moving, explicitly labeled exception rather than incorporating it into the smooth narrative of the main program.
This didn’t make the transition free for anyone. It made the costs visible, spread out, and manageable - which is not the same as solved.
Month 24 (effectively Month 27) - Result
Eighteen months after the initial triggering RFP, Vantric submitted a documented, differentiated remediation plan to its key customers - ahead of the customer’s internal deadline and before the 2030 threshold affecting the majority of the affected product cohort. The coprocessor-based interim measure was delivered to the 60% legacy cohort at an additional cost of approximately €1.85 per unit on the bill of materials - compared to an internal estimate that a complete redesign of the same cohort would have cost about 40 times the total budget of the coprocessor program in development hours and re-qualification alone.
Mr. K. did not resign. Eighteen months later, he was granted the budgetary authority he had lacked at the outset - not as a reward, but because the episode had concretely demonstrated that the gap between “Engineering knows” and “Engineering can act” was the actual cost driver, not the underlying technical debt itself.
What This Case Does Not Resolve
The coprocessor program addressed the cryptographic limitation in future production runs of a legacy product line. It relied, however, on a greenfield-adjacent logic - modifying the board design before assembly. What it leaves largely untouched is the far more formidable brownfield reality: the massive installed base of legacy units already operating in the field.
Field-deployed brownfield assets cannot be upgraded with a drop-in co-chip via a standard firmware update. Resolving the compliance gap for this installed base requires commercial and sales-driven retention strategies - such as structured trade-in programs, incentivized device swaps, or managed field-retrofit campaigns - rather than purely technical fixes. The design goal here shifts from engineering to customer relationship management: turning an impending compliance deadline into a structured lifecycle refresh without causing disruptive downtime or forced EOL for the customer’s active operations.
Furthermore, the following remained unaffected: the firmware update infrastructure for older field units, which had already been implemented prior to the fix; a separate, still-unresolved issue regarding a discontinued third-party radio module in another product line, for which no equivalent interim measure exists; and the commercial reality that every unit of cost avoided by an interim measure at Vantric was either absorbed by Vantric’s margin, passed on to a customer, or financed as debt.
The case is presented as an illustration of a functional process, not as proof that the underlying costs of decades of deferred investments can be eliminated through technology alone.
What the Case Illustrates
Nothing about this synthetic case required novel technology, a large budget, or a heroic individual. It required three things that happened in parallel rather than sequentially: an honest, nuanced assessment (not “everything is broken” or “nothing is broken,” but a distribution across cohorts); a culture of disclosure that treats an outdated plan as protective rather than incriminating; and a capital process willing to release funding against milestones rather than demanding complete certainty up front. The friction - supplier delays, internal politics, works council proceedings, sales resistance, customer costs, and the one genuine exception that could not be smoothed over - was real and was deliberately factored in: The framework of this paper is not a guarantee against friction, but merely a structure within which ordinary friction does not become a permanent delay, and within which the disruption that does occur is chosen and planned rather than forced.
> Non-Paper for discussion purposes. Independent analytical perspective.
Top comments (0)