Why the security inside a long-lived device may expire first
Understand why a product that remains in service for many years can face a security transition before the hardware reaches end of life.
Read the guide PRACTICAL RESOURCES
Start with the business problem, then work toward the technical decision.
These plain-language guides explain why connected-product manufacturers need to plan for quantum-safe security and what information a useful plan requires.
How to tell whether a device can accept quantum-safe security
Check the update path, memory, processing, storage, power, bandwidth, secure components, software stack, and supplier dependencies.
Read the guideWhen to update, redesign, replace, retire, or investigate
Turn technical findings into a product action with an owner, deadline, evidence, and a reason the business can review.
Read the guideThe device may last longer than its current security.
Connected products use public-key cryptography to prove identity, protect communications, verify software updates, and support secure startup. Future quantum computers could break many of the methods used for these jobs today.
No one needs to predict an exact date to begin planning. A product sold now may remain deployed for a decade or more. Hardware design, certification, manufacturing, field updates, and replacement can also take years. The useful question is whether the product can change before customers, regulators, or the product's own security lifetime require it.
Start by asking
- How long will this product remain in service?
- Which communications, identities, updates, or stored information must remain protected?
- How long would an update, redesign, certification, or fleet replacement take?
- Who owns the product decision?
A standard can be available and still not fit the device.
Quantum-safe algorithms have different demands on memory, processing time, storage, message size, power, and network bandwidth. The surrounding software, secure element, certificate system, supplier components, and update mechanism also matter.
A useful assessment follows every major product and hardware variant. It records what is known, what was tested on representative hardware, what came from a supplier, and what remains an assumption.
Evidence worth collecting
- Hardware and firmware baselines for each deployed variant
- Where public-key cryptography is used and why
- Update, rollback, secure-boot, and provisioning paths
- Memory, processing, storage, power, and communication limits
- Target-device test results and supplier commitments
The result should change a product plan.
An assessment is useful only when it leads to an owned decision. A product may be updated on existing hardware, redesigned for a future release, replaced in the field, retired before the deadline, or investigated because important evidence is missing.
Record the reason, supporting evidence, rejected alternatives, remaining risk, approver, and next review date. That creates a decision engineering teams can act on and product leaders can defend.
A complete output includes
- An action for each product and variant
- A list of evidence gaps and the tests needed to close them
- Owners, dependencies, and decision deadlines
- A portfolio roadmap for engineering and business review
- Customer, procurement, audit, and regulatory evidence where required
Apply the process to one device family.
Create a free Evaluation workspace and begin with the included synthetic case.