From Isolated Embedded Devices to Internet‑Exposed Systems: Why PSIRT Is Now a Must‑Have

Fact-сhecked

Embedded systems were historically designed as isolated solutions that performed strictly defined functions inside a closed infrastructure. In the early days, the threat model was mostly limited to physical access and internal configuration mistakes.

But as networking evolved and devices became connected to corporate networks and the wider internet, the risk landscape expanded dramatically. Remote access, cloud services, and integration with external systems turned embedded devices into full participants in the broader cyber environment.

Security in this new reality includes both a technical layer (device, network, infrastructure) and a human layer (processes, behavior, trust, and mistakes).

The Human Factor Didn’t Start With IoT

Long before “smart kettles,” smart bulbs, and modern IoT, hackers were already using social engineering to obtain the information they needed for unauthorized access.

A well-known example is Kevin Mitnick, an American computer security consultant and convicted hacker, who demonstrated that vulnerabilities may exist not in software, but in organizational processes and people’s trust. At the time, it wasn’t always the system itself that was vulnerable, people simply trusted it (and the attacker). Mitnick would call administrators, impersonate legitimate users, and obtain the access he needed.

His work helped illustrate a key idea that still holds today: system protection is not just a piece of hardware between external and internal networks, it’s an ongoing process.

The Internet Exposure Problem: Bigger Than It Looks

Today, a huge number of devices either have direct internet access (sometimes even with a static public IP address), or are connected via intermediary services that interact with them through predefined workflows.

Real-world practice shows that some devices supporting critical infrastructure may have 

• no effective access restrictions
• security left at default settings (for example: admin/admin)

Practical example: public warnings as a routine practice

Services like Shodan highlight the scale of the issue by indexing internet-exposed industrial automation devices.

In Germany, the Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI) regularly publishes warnings about such incidents, making it clear that this topic is not theoretical. And today, this is more relevant than ever.

Internet-exposed SCADA and energy systems (HMI panels, web interfaces for critical infrastructure, dispatching systems, and more) have long posed and continue to pose a serious threat to public safety and security. One example that explores this risk is the research titled “Investigation of risks for Critical Infrastructures due to the exposure of SCADA systems and industrial controls on the Internet based on the search engine Shodan” by Technische Hochschule Brandenburg.

Vulnerabilities Exist at Both the Physical and Software Levels

To prevent and mitigate threats, organizations use mechanisms to analyze vulnerabilities across multiple layers, including:

• Physical access vectors (e.g., via USB interfaces, CAN bus)
• Software access vectors (e.g., publicly exposed input/output ports, open services, misconfigured interfaces)

In this environment, it’s not enough for a manufacturing company to “build a secure system once.” Security requires continuous monitoring and response. And this is exactly where PSIRT comes in.

What Is PSIRT and Why It’s Not “Just a Team”

PSIRT stands for Product Security Incident Response Team. Despite the name, PSIRT is not merely a group of people responsible for a single product (or product line). In mature organizations, PSIRT is best understood as a repeatable process that includes:

• Monitoring publicly available and subscription-based security bulletins, for example the National Vulnerability Database (NVD) and Common Vulnerabilities and Exposures (CVEs).
• Evaluating how disclosed vulnerabilities affect the product.
• Regularly delivering security updates for deployed systems that the team supports.
• Coordinating communication with customers, clients, and external researchers.
• Publishing security advisories and related documentation.

In practice, PSIRT is not just reacting to CVEs. It is continuous monitoring, risk assessment, fixing, communication, documentation, and improvements to the development process.

PSIRT belongs inside the secure development lifecycle

A key point: PSIRT should be integrated into the product lifecycle, often discussed as Secure SDLC / SSDLC, rather than existing as an isolated function. For an accessible overview of secure development foundations, see OWASP’s guidance on Secure Development.

External testing also matters

A strong practice is also to collaborate with independent specialists who test systems for vulnerabilities from the outside, commonly known as penetration testers.

Why Embedded Products Are Especially Hard to Secure

Embedded systems almost always include a complex stack, for example:

• RTOS or an operating system based on the Linux/BSD kernel
• Third-party libraries (OpenSSL, mbedTLS, zlib, etc.)
• Device drivers
• Proprietary software components
• User interaction interfaces (UI and/or APIs)

Yes, there are important technologies that help, such as:

• Trusted Platform Module (TPM)
• Robust Auto-Update Controller (RAUC)
• Firmware/code signing 
• Rollback mechanisms to return to a previous firmware version

But these are only parts of the overall security system. Without an operational process around them, they won’t deliver their full value.

What a Well-Built PSIRT Process Should Do

A strong PSIRT process should do the following (at minimum):

Long Device Lifecycles Mean Long Security Obligations

Because embedded devices (especially in industrial automation) often have long lifecycles, manufacturers are expected to provide security support and updates over extended periods.

At the same time, even with a mature PSIRT process, security does not depend on the manufacturer alone. The final security posture is also shaped by:

• system configuration
• operational discipline
• timely patch deployment
• organizational controls and procedures

PSIRT, Regulation, and Standards: It’s Becoming Mandatory

PSIRT is increasingly part of broader product security governance.

Cyber Resilience Act in the EU

In the European Union, the Cyber Resilience Act (CRA) requires manufacturers of digital products to ensure cybersecurity throughout the product lifecycle. In effect, the CRA formalizes vulnerability management practices that PSIRT processes have traditionally implemented.

Three CRA Scenarios: What the Cyber Resilience Act Means for Your Business

Industrial automation: IEC 62443

In industrial automation, similar expectations are reflected in the IEC 62443 family of standards. In particular, IEC 62443-4-1 describes requirements for a secure development lifecycle, including vulnerability management processes.

Summing Up

Modern embedded systems are no longer isolated devices operating in closed environments. Once connected directly or indirectly to the internet and external services, they inherit the realities of the modern threat landscape.

A properly designed PSIRT process is not just a compliance checkbox. It is a practical mechanism that reduces cyber risk by enabling continuous vulnerability monitoring, applicability analysis, patching, communication, and lifecycle security improvements.

If your organization is building or operating embedded and IoT products, SaM Solutions can support you in designing, implementing, and maturing a PSIRT capability, from initial process setup to day-to-day vulnerability management.