What should open source maintainers who are monetizing their projects expect in terms of enforcement style and corrective actions from market surveillance authorities?

Monetizing open source maintainers should expect low-intensity, corrective-first enforcement focused on fixing concrete issues rather than penalties, unless their software causes clear cybersecurity risk at scale.

Authorities are likely to engage only where the maintainer's activities look commercial in practice—for example, paid support, hosted services, enterprise features, or control over releases—not where individuals contribute code without market control. For more on what constitutes monetization that triggers manufacturer status, see Am I subject to the CRA if I earn a living from the open source project I maintain?.

Based on patterns seen under GDPR enforcement, authorities will initially be reactive, responding to complaints, incidents, or known vulnerabilities. Typical actions will be requests to remediate—patching vulnerabilities, improving default security settings, or clarifying responsibilities—rather than immediate fines. All penalties must be "effective, proportionate and dissuasive" (Article 64; Recital 120).

Escalation is most likely if a maintainer who qualifies as a manufacturer ignores known vulnerabilities, misrepresents the security status of their software, or repeatedly fails to cooperate with authority requests. When penalties are imposed on natural persons or small entities, authorities must consider "the economic situation" and "size" of the entity (Recital 121; Article 64). Additionally, microenterprises and small enterprises are explicitly exempt from fines for failing to meet the 24-hour early warning notification deadline (Article 64(10)).

For more details on potential penalties, see If I maintain an open source codebase, and am treated as a "manufacturer" or "steward", what penalties could I face for violating the CRA?