Two loops meet at the secure product: secure product development before launch, post-launch product security after it. Both rest on management systems, risk management, development and production security, supply chain security, and culture and training.

* The development loop ends in the secure product, the post-launch loop keeps it secure, and five foundations carry both. *

The figure is a figure eight. The development loop runs through ten phases: security planning and classification, security requirements, threat modelling and risk assessment, security architecture and design, secure sourcing, secure implementation, security testing, security documentation, security certifications and DevSecOps. That loop produces the secure product.

The post-launch loop keeps it secure in the field: secure deployment and operation, maintenance and patching, configuration management, vulnerability management, information sharing, customer security collaboration, security monitoring, threat intelligence, incident and crisis handling, and finally secure end of life.

Neither loop works on its own. Below them sit the cross-cutting foundations: a cyber security management system, security risk management, development and production security, supply chain security, and organisation, culture, awareness and training. The loops are drawn as cycles because each release and each new vulnerability feeds back into the next round.

Go deeper:

• NIST SP 800-218 — Secure Software Development Framework (SSDF) — the US baseline of secure development practices, mapped to SDL-style lifecycles
• Secure by design (Wikipedia) — the principle behind building security into every phase

A product ships to customers and stays in the field for 10 to 20+ years, so it must be patchable and supportable long after the team that built it has moved on.

Information security protects the company's own IT. It can replace a server every five years, and it can patch on its own schedule because it owns the machines. A sold product, such as a laboratory analyser, a car or a PLC, belongs to the customer. It may run for decades on hardware and an operating system that were current at launch, often in places where updates need certification or downtime that the customer has to approve.

That lifespan is the key difference, and it explains the rest. Patching, testing and overall complexity matter in both disciplines. A long-lived product, though, needs a support and update path, spare cryptographic margin and a secure end of life planned from the start.

Go deeper:

• European Commission — CRA implementation FAQ — how the CRA turns lifespan into a legal support period
• Operational technology (Wikipedia) — why industrial products stay in the field for decades