CRA Art.9: Post-Market Monitoring — The Continuous Security Obligation That Doesn't End at Launch

Post #13 in the sota.io CRA Developer Series

Most compliance frameworks have a finish line. You audit, you fix, you certify, you ship.

The Cyber Resilience Act doesn't work that way.

Under Article 9, the obligation to monitor your product's security begins the day you place it on the market — and it doesn't end until the product reaches end-of-life. For SaaS developers and cloud service providers, that potentially means continuous security monitoring obligations for every product you have in active use.

This post breaks down what Art.9 actually requires, how it interacts with the rest of the CRA framework, and why CLOUD Act jurisdiction creates structural problems for US-parent SaaS trying to comply with EU post-market obligations.

What Article 9 Actually Says

Article 9 of the CRA establishes post-market monitoring as a mandatory obligation for all manufacturers of products with digital elements. The core text:

"Manufacturers shall monitor the security of products with digital elements they have placed on the market or put into service for the entire support period... Manufacturers shall investigate complaints and reports about security vulnerabilities in their products and keep records of these investigations."

The key obligations break down into three categories:

1. Continuous Security Monitoring

Manufacturers must actively monitor for vulnerabilities in their products — not just respond when users report issues. This means:

• Tracking CVE databases and security advisories for all components used in your product
• Monitoring third-party dependency vulnerability disclosures (NVD, OSV, vendor advisories)
• Watching for reports about your specific product across public channels
• Maintaining threat intelligence feeds relevant to your product category

For SaaS developers, this is continuous SDLC work that doesn't stop after deployment. Every library update, every cloud provider's security bulletin, every new CVE in your dependency tree is potentially a post-market monitoring event.

2. Vulnerability Investigation and Record-Keeping

When a vulnerability is identified (whether internally or externally reported), Art.9 requires manufacturers to:

• Investigate the reported vulnerability and assess its impact on affected products
• Keep records of the investigation — what was found, what was decided, what action was taken
• Maintain documentation sufficient to demonstrate compliance to market surveillance authorities

The record-keeping obligation is significant. It's not enough to patch quietly. You need to be able to show regulators how you became aware of the vulnerability, when you investigated it, and why you took the action you did.

3. Integration with the Notification Cascade

Post-market monitoring feeds directly into the other CRA notification obligations:

Art.9 is the foundation. Without systematic post-market monitoring, you can't reliably trigger the Art.11/Art.12/Art.14 obligations on time.

The Support Period Problem

One of the most misunderstood aspects of Art.9 is the support period concept.

The CRA requires manufacturers to define an explicit support period — the duration during which they commit to providing security updates. Article 13 and Annex II require this to be communicated to users upfront.

The post-market monitoring obligation runs for the entire support period.

For SaaS products, this creates an interesting question: When does the support period end?

Unlike traditional software (where v1.0 has a defined EOL), SaaS products are continuously updated. The implicit answer is: your support period is "as long as the service is operational." As long as users can access your product, you're in the monitoring window.

This means:

• You can't stop post-market monitoring for "old features" that are still accessible
• You can't reduce monitoring intensity for legacy API versions still in use
• If you sunset a product, you need explicit end-of-support communications and a defined transition period

What Post-Market Monitoring Requires in Practice

For a SaaS developer, a compliant post-market monitoring program needs at minimum:

Dependency Vulnerability Tracking

Sources to monitor:
- GitHub Security Advisories (GHSA)
- NVD (nvd.nist.gov)
- OSV (osv.dev) — for open source components
- Vendor advisories for commercial dependencies
- Language-specific advisories (PyPA, npm, RubyGems, etc.)

Tooling options (EU-hosted alternatives):
- Renovate Bot (self-hosted)
- Dependabot (GitHub — US parent, CLOUD Act applies)
- Snyk (Snyk Ltd, US parent)
- OWASP Dependency-Check (self-hosted, no US parent)

Security Report Intake

Users must have a way to report vulnerabilities (see also Art.14 and Annex II — the security.txt requirement). For Art.9 compliance, this intake channel must be:

• Monitored regularly
• Documented (timestamps, triage decisions, outcomes)
• Connected to your internal vulnerability handling process (Art.7)

Incident Documentation Log

A structured record of:

• Vulnerability discovered: date, source, CVE/GHSA reference
• Severity assessment: CVSS score, affected components, affected users
• Decision: patch, mitigate, accept, dispute
• Action taken: commit, deploy, notification
• Closure: date resolved, verification method

This doesn't need to be a formal system — a well-maintained spreadsheet satisfies the record-keeping obligation. But it needs to exist and be available to regulators on request.

SBOM Maintenance

Post-market monitoring is only effective if you know what you're monitoring. A maintained SBOM (required under CRA Annex I — see our CRA SBOM deep-dive) is the practical foundation for vulnerability tracking.

The CLOUD Act Collision

Here's where Art.9 gets complicated for US-parent SaaS.

Post-market monitoring requires access to security data and the ability to respond to it. For cloud SaaS, "responding" often means:

• Patching production infrastructure
• Modifying access controls
• Quarantining affected systems
• Coordinating with hosting providers

Under the US CLOUD Act (18 U.S.C. § 2713), US-parent companies can be compelled to produce data stored anywhere in the world. This creates a specific tension with Art.9 in two areas:

Monitoring Data Confidentiality

Your post-market monitoring logs contain sensitive information:

• Known vulnerabilities before they're patched
• Attack patterns affecting your infrastructure
• Internal triage decisions (including "we decided to accept this risk")

If your monitoring infrastructure runs on a US-parent cloud provider, this data is potentially compellable under CLOUD Act before you've had time to address the vulnerabilities. The competitive and legal consequences of pre-patch vulnerability disclosure are significant.

Response Capability Under Legal Hold

If a US authority issues a CLOUD Act demand that includes a non-disclosure order (standard practice), your post-market monitoring and response activities could become legally constrained at exactly the moment a vulnerability requires urgent action.

EU manufacturers running on EU infrastructure — without US-parent providers — face no equivalent constraint. Post-market monitoring, vulnerability investigation, and incident response happen entirely within EU legal jurisdiction.

The SaaS-Specific Interpretation

The CRA's scope relative to SaaS remains somewhat ambiguous in the final regulation text. The official CRA FAQ from the European Commission suggests that remote data processing products are in scope when they are "directly connected" to the user's devices or infrastructure.

The practical consensus among EU legal practitioners is:

In scope (likely):

• API-first SaaS that developers integrate into their own products
• Developer tools and CI/CD platforms with agent software
• IoT management platforms
• Identity and authentication services

Scope uncertain (watch ENISA guidance):

• Pure web-browser SaaS with no local components
• Consumer SaaS without EU developer integration

Even if your specific SaaS product ends up outside strict CRA scope, the NIS2 Directive and GDPR Art.32 create overlapping post-market security monitoring obligations that functionally require similar programs.

For B2B SaaS targeting EU customers, Art.9 compliance (or the equivalent under NIS2) is increasingly expected in enterprise procurement questionnaires regardless of strict legal scope.

Implementation Timeline: September 2026

The CRA becomes applicable on 11 September 2026 — now less than 120 days away.

For post-market monitoring, the practical implications:

The monitoring program needs to be running before go-live — you can't retroactively document vulnerabilities you didn't track.

What "Good" Post-Market Monitoring Looks Like

Based on guidance from ENISA and the BSI (German Federal Office for Information Security), a compliant post-market monitoring program includes:

✅ Automated dependency scanning (daily or per-commit)
✅ Vulnerability feed subscriptions for all major components
✅ security.txt pointing to a monitored intake channel
✅ Documented triage process (P0/P1/P2/P3 classification)
✅ Response SLAs tied to severity (24h for P0/P1)
✅ Incident documentation log (minimum: date, CVE, decision, action, resolution)
✅ SBOM updated on every release
✅ Defined support period communicated to users
✅ EOL process documented (advance notice + migration path)

The minimum viable version is smaller than you might expect. A well-documented process, consistently followed, satisfies Art.9 even if it's not automated.

The EU Infrastructure Advantage

For post-market monitoring specifically, EU-hosted infrastructure provides a structural advantage:

Monitoring logs and incident records stay within EU jurisdiction — not compellable under CLOUD Act.

Vulnerability response can proceed without risk of non-disclosure orders from US authorities affecting your incident response timeline.

Supplier relationships (hosting, CDN, monitoring tooling) operate under EU law — no equivalent of "US authority compels your CDN provider to provide traffic logs during an active security incident."

This matters for Art.9 compliance because your post-market monitoring capability is only as reliable as the infrastructure it runs on. If your monitoring stack includes US-parent cloud logging, security analytics, or dependency scanning services, your monitoring data is outside EU legal protection.

Key Takeaways

Art.9 post-market monitoring is perpetual: It runs from first deployment to end-of-life. There's no "compliance mode" to switch off after launch.

Record-keeping is mandatory: Investigation logs, triage decisions, and resolution documentation must be available to regulators. A spreadsheet with dates and CVE references is sufficient.

SaaS support periods are effectively infinite: As long as your product is accessible, you're in the monitoring window. EOL requires explicit communication.

CLOUD Act creates structural risk for US-parent SaaS: Monitoring data and incident response capability are potentially compellable or constrained by US legal process.

The monitoring foundation enables everything else: Without systematic Art.9 monitoring, you can't reliably trigger Art.11 (24h ENISA notification) or Art.12 (user notification) on time — creating cascading compliance failures.

The sota.io Angle

sota.io is an EU-native managed PaaS — no US parent company, running on Hetzner Germany. For developers building products that need CRA Art.9 compliance:

• Your monitoring logs, incident records, and vulnerability data stay within EU legal jurisdiction
• No CLOUD Act compellability of your post-market monitoring infrastructure
• EU-only supplier relationships for your hosting layer

CRA post-market monitoring requires reliable infrastructure with predictable legal behavior. EU-native hosting is the structural foundation that makes ongoing compliance achievable.

Further Reading in This Series

• CRA Art.10: Vulnerability Reporting to ENISA
• CRA Art.11: Actively Exploited Vulnerabilities — 24h Notification
• CRA Art.12: User Notification Requirements
• CRA Art.14: Coordinated Vulnerability Disclosure
• CRA SBOM Requirements
• CRA Annex I Essential Requirements Checklist
• CRA September 2026 Countdown