For years, dedicated Product Security Incident Response Teams (PSIRTs) were exclusively the domain of multinational tech giants—the Microsofts, Apples, and Ciscos of the world. If you were a small-to-medium enterprise (SME) building IoT devices, B2B software, or consumer electronics, vulnerability handling was likely an ad-hoc chore assigned to whichever senior developer happened to be online when an angry security researcher emailed the CEO.
The EU Cyber Resilience Act (CRA) permanently ends that era.
By September 2026, every manufacturer placing products with digital elements (PDEs) on the EU market must have formalized processes to receive vulnerabilities, acknowledge them within 48 hours, fix them promptly, and potentially report them to authorities within 24 hours.
You cannot meet these legal obligations on an ad-hoc basis. You need a PSIRT.
But if you are a 50-person engineering organization, you can't afford a dedicated team of 10 security analysts sitting in a watch floor. You need a . Here is a practical blueprint for establishing a compliant, effective product security capability from scratch, tailored for SMEs.
Demystifying the PSIRT
First, let's distinguish a PSIRT from a CSIRT (Computer Security Incident Response Team) or a SOC (Security Operations Center). CSIRT/SOC: Defends the company's* internal infrastructure (the corporate network, employee laptops, the cloud hosting environment). PSIRT: Defends the customers using the company's products. They handle vulnerabilities found in the code or hardware you sell*.
While a large enterprise separates these functions, an SME's MV-PSIRT often consists of individuals wearing multiple hats, borrowing from engineering, internal IT, and legal.
Step 1: Establish the "Front Door" (Tooling)
Before you define the human roles, you need the infrastructure to intake reports. You need a Coordinated Vulnerability Disclosure (CVD) process.
The Requirements:
- Visibility: A `security.txt` file at the root of your primary domains pointing to your policy.
- The Intake Mechanism: A dedicated portal (like CVD Portal) or a `security@` email alias. Do not use generic support ticketing systems; security reports must be segregated to prevent accidental exposure of zero-day exploits to frontline support staff.
- Secure Communication: The intake channel must support encryption (e.g., PGP keys for email, or forced HTTPS/TLS for portals) to protect the vulnerability details in transit.
Step 2: Define the Roles (The Humans)
In an MV-PSIRT, these are roles, not necessarily full-time specific job titles. One senior engineer might hold multiple roles.
1. The Triage Coordinator
This is the most critical role for daily operations.
- Responsibility: Monitors the intake channel. Acknowledges receipt within 48 hours (a strict CRA requirement). Performs the initial filtering to drop spam and beg-bounties.
- Profile: A junior-to-mid level engineer or a highly technical support specialist. They don't need to fix the bug, but they need to understand vulnerability terminology (XSS, Buffer Overflow, RCE) to identify credible reports.
2. The Vulnerability Analyst / Product Champion
- Responsibility: Reproduces the reported vulnerability in a safe environment. Assigns a CVSS severity score. Determines the blast radius (does this affect other products?).
- Profile: Senior developers, technical leads, or QA engineers familiar with the specific product architecture. In an SME, you likely won't have dedicated security analysts; you will rely on your senior developers to act as the subject matter experts for the code they wrote.
3. The Remediation Lead
- Responsibility: Drives the engineering fix. Ensures the patch doesn't introduce regressions. Coordinates the release schedule.
- Profile: An Engineering Manager or Team Lead. They own the engineering backlog and have the authority to pull developers off feature work to force a high-priority security patch.
4. The Incident Commander (The "Article 14" Czar)
- Responsibility: Makes the high-stakes calls. Has the authority to declare a "severe incident" or confirm "active exploitation," triggering the 24-hour CRA reporting cascade. Coordinates public communications and legal review.
- Profile: The CTO, VP of Engineering, or CISO. This person must have the organizational authority to bypass normal procedures during a crisis.
Step 3: Formalize the Playbook (The Process)
An MV-PSIRT is only as good as its documentation. You need a written playbook that dictates exactly what happens when a valid report arrives.
The Service Level Agreements (SLAs)
Define internal response limits based on CVSS severity. (These are examples; tailor them to your capacity, but keep CRA expectations in mind).
- Critical (CVSS 9.0 - 10.0): Triage in 4 hours. Remediation plan in 24 hours. Patch released in < 7 days.
- High (CVSS 7.0 - 8.9): Triage in 24 hours. Patch in next scheduled sprint (< 30 days).
- Medium/Low (CVSS 0.0 - 6.9): Triage in 48 hours. Patch within 90 days.
The "Active Exploitation" Protocol
Create a massive, bolded section in your playbook for 24-hour CRA reporting.
If a report indicates active exploitation (e.g., "I'm seeing this ransomware payload dropping on my network right now utilizing this flaw in your product"), the normal SLAs vanish. The Incident Commander is paged immediately to begin drafting the Early Warning notification to the national CSIRT.
Disclosure and Advisories
Define the format for your public security advisories once the patch is live. You must credit the researcher (if they desire), list the CVE ID, explain the impact, and provide clear update instructions. Move toward machine-readable formats (CSAF 2.0) to ease compliance reporting.
Step 4: Run a Tabletop Exercise
Do not test your PSIRT playbook for the first time during an actual crisis.
Schedule a 2-hour "Tabletop Exercise" with your designated MV-PSIRT members. Present a simulated scenario:
- Scenario: "It's 4:00 PM on a Friday. A researcher emails the
security@alias stating they have found an unauthenticated remote code execution (RCE) zero-day in our flagship IoT controller. They provided a Python script that perfectly exploits the firmware. What do you do?"
Walk through the playbook step-by-step. Who acknowledges the email? Who provisions the test environment? Who scores it? If the researcher says they intend to publish the details on Monday, what is your crisis communication strategy?
Identify the gaps in your process and iterate on the playbook.
Conclusion
Building a PSIRT from scratch is intimidating, but it doesn't require millions of dollars in budget or hiring a dedicated security army. It requires intent, organization, and a clear understanding of your legal obligations under the CRA. By establishing a formalized front door, assigning clear roles to existing engineering talent, and rigorously defining your response SLAs, SMEs can build a highly capable Minimum Viable PSIRT ready for whatever hits their inbox.