---
key: "product-security-obligations"
title: "Cyber Resilience Act and payment pages: turn product-security obligations into an engineering evidence plan"
url: "https://softwaresecurity.com/frameworks/product-security-obligations/"
api: "https://softwaresecurity.com/api/v1/articles/product-security-obligations.json"
domain: "governance"
topic: "Governance \u0026 frameworks"
type: "Guide"
identifiers: []
tags: ["Vulnerability disclosure","AppSec programs","Regulation"]
stages: ["respond","govern"]
roles: ["appsec-engineer","security-leader"]
license: "CC-BY-4.0"
license_url: "https://creativecommons.org/licenses/by/4.0/"
code_license: "MIT"
---

# Cyber Resilience Act and payment pages: turn product-security obligations into an engineering evidence plan

Determine the relevant actor, product, market and requirement before connecting CRA or payment-security expectations to implementation work.

Canonical URL: https://softwaresecurity.com/frameworks/product-security-obligations/

## In short

Decide first whether the product, your role and the market are in scope, then plan by date. Under the EU Cyber Resilience Act, manufacturers must report actively exploited vulnerabilities and severe incidents from 11 September 2026, including for products already on the market: early warning within 24 hours, notification within 72 hours, then a final report, through ENISA’s Single Reporting Platform. Annex I, a five-year minimum support period and conformity assessment apply from 11 December 2027.

- CRA reporting under Article 14 applies from 11 September 2026 to every product in scope, including those placed on the market before 11 December 2027 (Art. 69(3)).
- Reports go through ENISA’s Single Reporting Platform to the CSIRT designated as coordinator, which ENISA receives at the same time.
- Clocks run from awareness: early warning in 24 hours and notification in 72; the final report is due 14 days after a fix or mitigation is available, or one month after an incident notification.
- From 11 December 2027, products must meet Annex I, have a support period of at least five years (Art. 13(8)) and pass the conformity assessment for their class.
- PCI DSS v4.0.1 requirements 6.4.3 (authorize, integrity-check and inventory every payment-page script) and 11.6.1 (detect changes at least weekly) have applied since 31 March 2025.
- An SBOM supports Annex I Part II but proves neither secure design nor a working reporting process.

## Recommended defaults

| Setting | Value | Note | Source |
| --- | --- | --- | --- |
| CRA early warning | Within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident | — | Regulation (EU) 2024/2847, Art. 14(2) and 14(4) |
| CRA notification | Within 72 hours of becoming aware | — | Art. 14(2) and 14(4) |
| CRA final report | 14 days after a corrective or mitigating measure is available (vulnerability); one month after the incident notification (incident) | — | Art. 14(2) and 14(4) |
| CRA reporting channel | ENISA Single Reporting Platform, to the CSIRT designated as coordinator, with ENISA notified at the same time | — | Art. 14(1) and 16; Commission CRA reporting page |
| CRA support period | At least 5 years, or the expected time in use if that is shorter | — | Art. 13(8) |
| PCI DSS payment-page change detection | At least weekly, or at the frequency set by a targeted risk analysis | — | PCI DSS v4.0.1 requirement 11.6.1 |

## Verify it

1. Run a reporting drill: from a simulated awareness time, produce the early warning within 24 hours and record who decided what.
2. Confirm each product version has a published support end date of at least five years, or a recorded reason for a shorter expected use.
3. Check that the coordinated disclosure policy and reporting contact are published and monitored.
4. List every script on the payment page and its parent page with an owner, a justification and an integrity check.
5. Change one script on a test payment page and confirm the 11.6.1 mechanism alerts.

## What you will learn

- Separate legal duties, assessment standards and voluntary guidance.
- Calculate CRA manufacturer clocks only after actor/event scope is established.
- Build product-specific evidence without inferring compliance from an SBOM or outsourced payment flow.

Audience: Product security and engineering leads at manufacturers selling software in the EU or taking card payments

Before you start:

- Identify product type, markets, distribution role, support commitments and responsible counsel.

Time: About 29 minutes: 8 to read and 21 for the exercise

## Which obligation applies to which product?

An obligation needs a source, actor, product, jurisdiction, effective date and triggering fact. A law, an industry assessment standard, a contract and voluntary development guidance do not have the same status. Engineering can supply product and system facts, while the designated legal/compliance and assessment roles determine the applicable route. A useful record identifies unresolved scope questions rather than filling them with assumptions drawn from a framework name.

The fictional company Alder distributes a paid connected desktop client into the EU and runs a web checkout using a payment provider. The client and checkout need different scope records. For the Cyber Resilience Act, Regulation (EU) 2024/2847, relevant questions include whether the client is a product with digital elements, the company's actor role, applicable exclusions and conformity route. A pure service and a product's necessary remote processing may require different analysis. Payment outsourcing raises a separate question about the checkout environment; it does not decide CRA applicability. Other regimes reach software products too: NIS2 and DORA through customers (/frameworks/nis2-dora-for-software-suppliers/), the UK's voluntary code (/frameworks/uk-software-security-code-of-practice/) and sector lifecycles for medical, industrial and automotive products (/frameworks/regulated-product-security-lifecycle/).

## What CRA evidence does a product need beyond reporting?

The Cyber Resilience Act entered into force on 10 December 2024. Its manufacturer reporting duties apply from 11 September 2026 and everything else from 11 December 2027. Reporting distinguishes actively exploited vulnerabilities from severe incidents, and Article 69(3) applies it to every product in scope, including products placed on the market before December 2027. Open-source software stewards have reporting duties of their own from 11 December 2027 (Art. 24(3)), so the manufacturer timeline must not be generalized to every actor.

The exercise stipulates that the fictional qualified reviewer has classified the actor and event for clock arithmetic. It does not ask the reader to make a legal conclusion from incomplete facts. Engineering’s useful work is preserving awareness time, affected versions, exploit evidence, mitigation state, update artifacts and contacts. Product obligations also need a persistent dossier for risk analysis, support, vulnerability handling and secure updates. An SBOM helps document components, but it cannot by itself demonstrate secure design, an effective reporting process or the required conformity assessment.

## Which CRA dates apply now?

Plan against the dates in the Regulation, not against summaries of an earlier draft. The first three dates have passed, so the reporting duties already apply.

| Date | What applies | Provision |
| --- | --- | --- |
| 10 December 2024 | The Regulation enters into force | Art. 71(1) |
| 11 June 2026 | Rules for notified bodies and other conformity assessment bodies | Art. 71(2), Chapter IV |
| 11 September 2026 | Manufacturers report actively exploited vulnerabilities and severe incidents, for products placed on the market before or after this date | Art. 14, 69(3) and 71(2) |
| 11 December 2027 | Every other obligation, including Annex I, the support period, conformity assessment and CE marking; open-source stewards’ reporting | Art. 71(2) and 24(3) |

## How do you report an exploited vulnerability or severe incident?

Submit each stage through ENISA’s Single Reporting Platform. It routes the report to the CSIRT designated as coordinator in the Member State of your main establishment (Article 14(7) sets the order when you have none) and makes it available to ENISA at the same time. Every deadline counts from awareness and is an outer limit: the early warning and notification are due without undue delay.

Inform the impacted users, and where appropriate all users, about the vulnerability or incident and the mitigations they can apply (Art. 14(8)). The function below computes the outer deadlines for the record; it does not decide whether an event is reportable. For the full procedure, see /frameworks/cra-reporting-runbook/.

```python
"""Outer deadlines for a manufacturer's notifications under CRA Article 14."""

import calendar
from datetime import timedelta


def plus_one_month(t):
    """The same day next month, or that month's last day when it is shorter."""
    year, month = (t.year + 1, 1) if t.month == 12 else (t.year, t.month + 1)
    return t.replace(
        year=year, month=month, day=min(t.day, calendar.monthrange(year, month)[1])
    )


def cra_deadlines(kind, aware, fix_available=None, notified=None):
    """kind is "exploited_vulnerability" (Art. 14(2)) or "severe_incident" (Art. 14(4)).

    The clocks run from the moment the manufacturer became aware. These are outer
    limits: the early warning and notification are due "without undue delay" and
    at the latest by then.
    """
    deadlines = {
        "early_warning": aware + timedelta(hours=24),
        "notification": aware + timedelta(hours=72),
    }
    if kind == "exploited_vulnerability" and fix_available:
        deadlines["final_report"] = fix_available + timedelta(days=14)
    elif kind == "severe_incident" and notified:
        deadlines["final_report"] = plus_one_month(notified)
    return deadlines
```

| Event | Early warning | Notification | Final report |
| --- | --- | --- | --- |
| Actively exploited vulnerability | 24 hours after awareness | 72 hours after awareness | 14 days after a corrective or mitigating measure is available |
| Severe incident | 24 hours after awareness | 72 hours after awareness | One month after the incident notification |

## What does the CRA require of the product from December 2027?

Annex I Part I sets properties a product must have based on its risk assessment, such as no known exploitable vulnerabilities at release, a secure default configuration, security updates, protection from unauthorized access, data minimization and security logging. Part II sets the manufacturer’s vulnerability handling. Article 13(8) requires a support period of at least five years, unless the product is expected to be in use for less time.

The conformity route depends on the product’s class. Most products may use internal control (self-assessment). Important products in Annex III Class I may self-assess only if they apply harmonised standards, common specifications or a European cybersecurity certification at assurance level “substantial”; otherwise, and always for Class II, a notified body takes part. Critical products in Annex IV need a European cybersecurity certificate where the Commission requires one, or else a Class II route. Harmonised standards are being drafted under standardisation request M/606 of February 2025, and a standard gives a presumption of conformity only once its reference is published in the Official Journal; check the Commission’s CRA standardisation page before relying on one.

| Annex I Part II duty | Related guide on this site |
| --- | --- |
| 1. Identify components, including a machine-readable SBOM | /domains/supply-chain/sbom/generate-release-inventory/ |
| 2. Remediate without delay, with security updates kept separate from feature updates where feasible | /domains/appsec/vulnerability-response/dependency-vulnerability-response/ |
| 3. Test and review security regularly | /domains/appsec/testing/sast-dast-workflow/ |
| 4–6. Publish fixed vulnerabilities, enforce a coordinated disclosure policy and provide a reporting contact | /domains/appsec/vulnerability-response/coordinated-disclosure/ |
| 7–8. Distribute updates securely and without delay, free of charge, with advisories | /domains/supply-chain/releases/trusted-publishing-and-updates/ |

## Where is the payment boundary, and who decides the assessment route?

PCI DSS v4.0.1 is the edition in PCI SSC's official library. E-commerce script and tamper-detection requirements became effective on 31 March 2025, while PCI SSC also changed SAQ A content and eligibility guidance. The distinction matters: a change to a self-assessment questionnaire is not a declaration that all merchants may ignore payment-page risk. Determine the actual integration, systems able to affect payment security and validation route with the responsible assessment parties.

Alder's page loads a company-controlled analytics script around an embedded payment flow. Engineering can inventory scripts, identify their sources and authorization, document what data they can access, and test change detection. Those observations support a scope/requirements review; they do not by themselves establish which SAQ Alder may use. A third-party processor does not remove every merchant-side influence on the payment experience. Conversely, it would overstate scope to label every corporate system part of the cardholder-data environment solely because a website takes payments.

## What do PCI DSS 6.4.3 and 11.6.1 require for payment pages?

Two PCI DSS v4.0.1 requirements target e-skimming. Requirement 6.4.3 says every script loaded and executed in the consumer’s browser on a payment page must be authorized, have its integrity assured, and be listed in an inventory with a written justification. Requirement 11.6.1 requires a mechanism that alerts on unauthorized changes to the security-impacting HTTP headers and the script contents of payment pages as the browser receives them, run at least weekly or at a frequency set by a targeted risk analysis. Both are covered with the rest of Requirement 6 in /frameworks/pci-dss-requirement-6/.

PCI SSC’s March 2025 information supplement explains the scope for Alder’s design: when the payment form is embedded in an iframe, the merchant answers for the scripts on its own parent page and the payment provider for the scripts inside the iframe. It names Content Security Policy and Subresource Integrity as example integrity controls. SAQ A does not include 6.4.3 or 11.6.1, but its eligibility criteria require the merchant to confirm the site is not susceptible to attacks from scripts that could affect its e-commerce systems.

## How do you join provision, owner and release without claiming legal completion?

Maintain a requirement-to-release record with instrument/edition, exact provision, actor/product scope, effective date, implementation owner, evidence IDs, assessor/reviewer, open questions and next-review trigger. Keep binding text separate from explanatory guidance, drafts and future plans. Commission guidance supports interpretation but does not replace the regulation; PCI SSC guidance and questionnaires support the applicable assessment route but do not make a product legally compliant by association.

In the fixture, the client updater rejects a tampered package but lacks a documented support-end date. That is one demonstrated technical behavior and one unresolved product commitment. The checkout's script inventory lacks a change-detection observation. A good evidence plan preserves both rather than marking the whole product complete because one security test passed. Changes in markets, distribution roles, product features or payment integrations reopen applicability. The guide covers engineering preparation and conditional clock calculation; legal applicability, conformity assessment and PCI validation belong to the responsible legal and assessment roles.

## Guided practice

Prepare Alder’s two-track evidence plan. The reporting classification below is a stipulated fictional reviewer decision solely for arithmetic.

### Supplied material

```text
Product C4: paid connected desktop client distributed under Alder brand to EU customers; auto-updater; legal actor/exclusion/conformity review normally required.
For this exercise only, reviewer LR1 has determined Alder is a covered manufacturer and event V7 is an actively exploited vulnerability subject to the stated CRA manufacturer reporting clocks.
Awareness V7: 2026-10-07 10:00 UTC. Corrective measure available: 2026-10-12 10:00 UTC. Use calendar hours/days; no time-zone conversion.
E1 client C4 tampered update rejected; E2 component inventory bound to C4; support-end date missing.
Checkout P2: third-party embedded payment flow; Alder analytics script executes on parent page; script inventory E3 lists source/purpose; no tamper-detection observation; PCI assessment route undecided.
Roles: engineer Mira collects evidence; legal reviewer LR1 owns legal applicability; payment assessor role PA1 owns validation-scope advice. No real reporting or approval is requested.
```

### 1. Create separate applicability rows

Name the subject and decision owner for CRA and PCI.

Worked answer: CRA row concerns client C4, Alder actor/market and legal provisions, owned for review by LR1. PCI row concerns checkout P2 and systems influencing payment security, with PA1. Neither row inherits a conclusion from the other.

### 2. Calculate the stipulated reporting times

Apply the supplied manufacturer clocks without reclassifying the event.

Worked answer: Early-warning outer deadline: Oct 8 2026 10:00 UTC (24 hours). Notification: Oct 10 10:00 UTC (72 hours). For the stipulated actively exploited vulnerability, final-report outer deadline is Oct 26 10:00 UTC, 14 days after corrective measure availability. Duties requiring action without undue delay still matter; these are not suggested waiting times.

### 3. Assess the client dossier

State what E1/E2 prove and identify an unresolved obligation input.

Worked answer: E1 supports one updater integrity behavior for C4; E2 supports component inventory binding. Neither resolves product classification or conformity route, and the missing support-end date matters: Article 13(8) requires at least five years unless the product is expected to be in use for less. Record the end date and its reason, and retain the specific tested artifact identities.

### 4. Assess the payment evidence

Reject two overbroad inferences from payment outsourcing.

Worked answer: Do not infer no merchant scope because processing is outsourced; Alder scripts can affect the page. Also do not infer every system is in scope. Supply data-flow/script evidence and obtain the applicable assessment route before assigning exact requirement verdicts.

### 5. Write the evidence plan

Assign two missing artifacts and a change trigger.

Worked answer: Mira prepares client support record E4 and checkout change-detection test E5; LR1 reviews product-role/applicability; PA1 reviews payment route. Reopen when client distribution/roles or checkout scripts/integration change. No compliance or submission claim is made.

Deliverable: A two-track applicability/evidence worksheet and three conditional reporting deadlines.

Scope: The clock calculation assumes a fictional qualified scope/event determination. Real reporting, conformity and payment validation require current authoritative provisions and the responsible review process.

Articles and teaching material: CC BY 4.0. Original executable code: MIT. Attribution: Software Security.

## Sources

- [Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng). OJ L 2024/2847, 20 November 2024.
- [European Commission: CRA reporting obligations](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting)
- [European Commission: Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)
- [European Commission: CRA standardisation](https://digital-strategy.ec.europa.eu/en/policies/cra-standardisation)
- [PCI SSC document library: PCI DSS v4.0.1](https://www.pcisecuritystandards.org/document_library/?category=pcidss&document=pci_dss). v4.0.1 (June 2024).
- [PCI SSC: new information supplement, Payment Page Security and Preventing E-Skimming](https://blog.pcisecuritystandards.org/new-information-supplement-payment-page-security-and-preventing-e-skimming). 10 March 2025.
- [PCI SSC: important updates for merchants validating to SAQ A](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a). 30 January 2025.