Do you know what each piece of your finance stack can reach?

The news about your software now travels on a clock.

For as long as most finance teams have been buying software, the way you found out that something you run was being attacked was informal. A vendor newsletter, a support portal you remembered to check, a security colleague who follows the right mailing lists, or a customer asking an uncomfortable question. The timing was whatever the vendor chose, the format was prose, and the burden of noticing sat entirely on the buyer.

That changed on 11 September 2026. Article 14 of Regulation (EU) 2024/2847, the Cyber Resilience Act, now requires the manufacturer of a product with digital elements to notify any actively exploited vulnerability it becomes aware of, simultaneously to the national computer security incident response team designated as coordinator and to ENISA. The first notification is due within 24 hours. A fuller one follows within 72 hours, and it has to cover the product concerned, the general nature of the exploit and the vulnerability, and the corrective or mitigating measures taken, including measures that users can take. A final report is due no later than 14 days after a corrective or mitigating measure is available. ENISA launched the Single Reporting Platform on the same day, so a manufacturer reports once and the receiving CSIRT passes the information to other Member States where the product is available.

The timing is worth pausing on, because it is unusual. Article 71(2) applies the Regulation as a whole from 11 December 2027, and then pulls Article 14 forward by fifteen months. The product design requirements, the conformity assessment, the CE marking and the support period rules all arrive later. The reporting duty arrived first, deliberately, and it is live now.

Most commentary on this has been written for manufacturers, which is reasonable since they carry the obligation. The part that matters to everyone else sits in Article 14(8). After becoming aware of an actively exploited vulnerability or a severe incident, the manufacturer must also inform the impacted users of the product, and where appropriate all users, of that vulnerability or incident and, where necessary, of any risk mitigation and corrective measures the users can deploy. Then comes the clause worth reading twice: where appropriate in a structured, machine-readable format that is easily automatically processable.

The same paragraph adds a backstop. Where the manufacturer fails to inform users in a timely manner, the notified CSIRTs may provide the information to users themselves, where they consider it proportionate and necessary. So the notice about your finance system may arrive from your vendor, or it may arrive from a national CSIRT in a country you operate in, in a language you were not expecting, on a day nobody is watching that inbox.

One more scope point is easy to miss and it matters more than most. The European Commission, announcing the start date, states that the reporting obligations apply to all products with digital elements made available in the EU, including those already on the market. The tax engine installed in 2019, the bank connectivity agent nobody has upgraded since the treasury project finished, the ageing e-invoicing connector still running because it works: all of them are inside the scope of a notification you might receive.

Read as compliance, none of this is your problem. You are not a manufacturer, and Article 14 puts no obligation on a buyer at all. Read as operations, it is a genuine improvement in the quality and speed of information reaching you about software you depend on, arriving with a legal clock behind it and, at least sometimes, in a form a machine can read. The question it raises is not about compliance. It is whether your side of the exchange is ready to do anything with it.

What the Regulation says, and when each part bites.

The text is more specific than the summaries suggest, and the specifics are where the useful design cues are. The table below works through the provisions that touch a buyer, taken from the Regulation itself rather than from a précis. The third column matters as much as the second, because this Regulation arrives in two waves and it is easy to plan against a requirement that does not apply for another fifteen months.

Three of those rows deserve more than a line. The first is the definition of an actively exploited vulnerability in Article 3: a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner. That is a narrow trigger. It is not a scanner finding, not a high severity score, not a theoretical weakness. A notice under Article 14 means someone, somewhere, is being attacked through this thing. Very few of the alerts a finance systems owner sees in a year clear that bar, which is precisely what makes these worth building a process around.

The second is Annex I Part II(2), which requires manufacturers to remediate without delay and adds that where technically feasible, new security updates shall be provided separately from functionality updates. That one sentence addresses the single most common reason a finance system sits unpatched. Taking a security fix has historically meant taking whatever else came in the release, which means regression testing a configuration that took months to validate, which means the fix waits for the next planned window. A requirement to ship security updates on their own changes that calculation. It applies from 11 December 2027 rather than now, so it belongs in a procurement conversation and a roadmap rather than in this quarter’s plan.

The third is Annex II(7), which requires the product to be accompanied by the end-date of the support period during which users can expect vulnerabilities to be handled and to receive security updates, with Article 13(8) setting that period at a minimum of five years unless the product is expected to be in use for less. A published end-date is a small thing that changes a recurring argument. Every finance function has a version of the conversation about when to upgrade a system that still works. Held as a date in the vendor master across the whole stack, sorted ascending, that conversation becomes a list with an order to it.

The answer arrives against a product. The exposure belongs to an installation.

Here is the shape of the problem, stripped of the regulation. A notice arrives naming a product and a range of affected versions. To act on it you need to answer four questions quickly: do we run this, at what version and in how many places, which legal entities and banking relationships depend on those places, and what is each of those installations actually allowed to do. The first three are the sort of thing most organisations believe they can answer and discover they can only approximate. The fourth is rarely recorded anywhere at all, and it is the one that decides everything about the response.

The mismatch that costs the most time is between how a vendor names a product and how you do. An advisory identifies the affected thing the way Annex I Part II(4) will eventually require, with information allowing users to identify the product affected, which in practice means a package or platform identifier and a version range. A purchasing record holds the name on the invoice, the reseller, and a version that was accurate at go-live. Those two do not join. Every hour spent working out whether the advisory refers to the thing you own is an hour spent inside a window where someone is being actively attacked through it.

The second mismatch is between product and installation. One product often runs in several places, at different versions, serving different entities. The notice arrives against the product. The exposure, the entities affected and the decision about what to turn off all belong to a specific installation. An inventory keyed at product level produces the answer that the company both does and does not run the affected version, which is true and useless.

The column that earns its place is the one describing what the installation can do. Finance systems are not equally consequential, and the ordering is not the one a licence schedule would suggest. The most expensive system in the stack is frequently a reporting layer that can only read. The one that should be handled first is often a small connector nobody thinks about, because it holds a credential that can authenticate to a bank. Sorting by capability rather than by cost is the single change that makes an incident response list match the actual risk.

Two of those tiers behave differently from the rest. Credential custody is the one where the useful response has a lead time attached. If a connector holding a bank channel credential is named in a notice, the honest assumption is that the credential may be exposed, and the response is rotation. Rotation involves the bank, sometimes a physical token, sometimes a scheduled window, and it very rarely takes an hour. Knowing that number in advance, per relationship, is the difference between a decision and a discovery.

Master data write is the tier most often underrated. A payment that should not have gone out is visible the same day. A vendor bank account quietly changed in the master record is visible when the real supplier calls about a missing payment, which can be a month later and several runs further on. When something with master data write authority is named in a notice, the response includes looking backwards at recent changes, not only forwards at new ones.

# One row per installation, not per product. The notice arrives against a
# product; the exposure belongs to the place it actually runs.

product:
  product_id: "PRD-0147"
  commercial_name: "Bank connectivity gateway"
  manufacturer: "VENDOR-PLACEHOLDER-A"
  # what an advisory will use to name this thing, not what procurement typed
  identifiers:
    - scheme: "cpe"
      value: "cpe:2.3:a:vendor_placeholder_a:connect_gateway:*:*:*:*:*:*:*:*"
    - scheme: "purl"
      value: "pkg:generic/vendor-placeholder-a/connect-gateway"
  security_contact: "security@vendor-placeholder-a.example"   # Article 13(17)
  security_contact_verified_on: "2026-08-04"
  cvd_policy_url: "https://vendor-placeholder-a.example/security"  # Annex II(2)
  support_period_end: "2029-06-30"        # Annex II(7), from 11 Dec 2027
  support_period_source: "vendor product documentation, retrieved 2026-08-04"

installations:
  - installation_id: "INST-0147-EU-01"
    product_id: "PRD-0147"
    version: "8.4.2"                      # exact, so a range can match it
    environment: "production"
    hosting: "self-hosted"                # or "vendor-hosted-rdps"
    effective_from: "2026-03-11"
    effective_to: null                    # keep history, do not overwrite
    # the column that decides everything about the response
    capabilities:
      - "payment_initiation"
      - "credential_custody"
    capability_tier: "highest"
    legal_entities: ["RIV-DE-01", "RIV-NL-02", "RIV-IE-01"]
    bank_relationships: ["BANK-A-EUR", "BANK-B-EUR"]
    credential_rotation_hours: 6          # known in advance, not discovered
    compensating_controls:
      - control: "auto_release_threshold"
        normal_value: 250000
        incident_value: 0
      - control: "dual_release_required"
        normal_value: false
        incident_value: true

notifications:
  - notification_id: "CRA-2026-0093"
    received_at: "2026-09-18T19:42:00Z"
    source: "manufacturer"                # or "csirt", per Article 14(8)
    stage: "72h_vulnerability_notification"
    affected_identifier: "pkg:generic/vendor-placeholder-a/connect-gateway"
    affected_versions: ">=8.0.0 <8.4.5"
    matched_installations: ["INST-0147-EU-01"]
    assessed_by: "PLACEHOLDER-OWNER"
    assessed_at: "2026-09-18T20:15:00Z"
    actions:
      - action: "auto_release_threshold set to 0"
        at: "2026-09-18T20:21:00Z"
        approved_by: "PLACEHOLDER-APPROVER"
        reverted_at: "2026-09-22T09:05:00Z"
    remediated_by_change: "CHG-11284"
    closed_at: "2026-09-22T09:30:00Z"

# The exception query. Run it on a schedule, not after a notice arrives.
# Every row it returns is a question you cannot answer under time pressure.

SELECT installation_id, reason FROM (
  -- no machine-matchable identifier, so an advisory cannot be joined
  SELECT i.installation_id, 'no product identifier held' AS reason
    FROM installations i JOIN product p ON i.product_id = p.product_id
   WHERE NOT EXISTS (SELECT 1 FROM identifiers d WHERE d.product_id = p.product_id)
  UNION ALL
  -- version recorded loosely, so a version range cannot be evaluated
  SELECT installation_id, 'version not exact'
    FROM installations
   WHERE version IS NULL OR version NOT SIMILAR TO '[0-9]+(\.[0-9]+)+%'
  UNION ALL
  -- no capability tier, so no service level and no response order
  SELECT installation_id, 'capability tier unset'
    FROM installations WHERE capability_tier IS NULL
  UNION ALL
  -- can move money with no compensating control defined in advance
  SELECT installation_id, 'payment capability without a defined lever'
    FROM installations
   WHERE 'payment_initiation' = ANY(capabilities)
     AND NOT EXISTS (SELECT 1 FROM compensating_controls c
                      WHERE c.installation_id = installations.installation_id)
  UNION ALL
  -- holds a credential but rotation time is unknown
  SELECT installation_id, 'credential custody with unknown rotation time'
    FROM installations
   WHERE 'credential_custody' = ANY(capabilities)
     AND credential_rotation_hours IS NULL
  UNION ALL
  -- nobody knows which entities would be exposed
  SELECT installation_id, 'no legal entity mapping'
    FROM installations
   WHERE legal_entities IS NULL OR cardinality(legal_entities) = 0
  UNION ALL
  -- security contact missing or stale beyond a year
  SELECT i.installation_id, 'security contact missing or stale'
    FROM installations i JOIN product p ON i.product_id = p.product_id
   WHERE p.security_contact IS NULL
      OR p.security_contact_verified_on < current_date - INTERVAL '365 days'
  UNION ALL
  -- support period ends within a year and no successor plan is recorded
  SELECT i.installation_id, 'support period ending, no plan'
    FROM installations i JOIN product p ON i.product_id = p.product_id
   WHERE p.support_period_end < current_date + INTERVAL '365 days'
     AND i.successor_plan IS NULL
  UNION ALL
  -- a temporary control applied and never restored
  SELECT a.installation_id, 'compensating control not reverted'
    FROM notification_actions a
   WHERE a.reverted_at IS NULL
     AND a.at < current_timestamp - INTERVAL '30 days'
) exceptions
ORDER BY reason, installation_id;

The exception query at the foot of that record is the part worth implementing first, and it is deliberately dull. Every row it returns is a question you would otherwise be answering under a clock: an installation with no identifier an advisory could match, a version recorded as roughly current, a payment capable system with no lever agreed in advance, a credential holder whose rotation time nobody knows. Running it monthly turns the whole of this from an incident response capability into a piece of housekeeping, which is a much easier thing to sustain.

If your organisation already collects bills of materials from software vendors, the two join naturally and each makes the other more useful. A bill of materials answers what is inside a product. An Article 14 notice answers when something inside one is being exploited. We wrote about the first half of that in the vendor master data design for software bills of materials, and the component identifiers are the shared key between them.

Between the notice and the fix, finance has levers that work in minutes.

The gap that matters is the one between the 72 hour notification and a deployed fix. It can be days. It is sometimes longer, because a security update to a finance system still has to pass through change management, and because Annex I Part II(2) does not require security updates to ship separately from functionality updates until 11 December 2027. During that gap the standard security answer, which is to patch, is not available yet.

Finance is unusually well equipped for that gap, and it tends not to realise it. The levers are already built, already governed, and can be pulled in minutes: lower the automatic release threshold, or take it to zero so every payment needs a person. Require dual release on the affected channel. Freeze the bank detail change workflow on the vendor master. Put a manual hold in front of filing transmission. Move an integration’s write path behind a staging review so postings can be inspected before they land. None of these is a security control in the usual sense. Each of them substitutes a human decision for an automated one for a bounded period, which is exactly the right trade while the integrity of a system is uncertain.

Deciding which lever belongs to which capability tier is work that takes an afternoon, and it has to happen while nothing is going on. A notice arriving at 7pm on a Friday is a bad moment to be forming a view on whether dropping the auto-release threshold to zero will strand a payroll run. Written down in advance, with the payroll exception already considered, it becomes a decision someone can take with confidence.

The other half of doing this well is leaving a trace. A threshold lowered for four days and then restored is a control that operated. Recorded with the notification it responded to, the approval, the effective times and the restoration, it reads later as exactly that. Handled informally over a call, the same action shows up in a configuration change review as an unexplained edit to a payment control, which is a conversation nobody enjoys. The record costs almost nothing at the time and is worth a great deal afterwards.

The inbound channel deserves one decision of its own. Because Article 14(8) allows a CSIRT to inform users where the manufacturer has not, notices can arrive from more than one direction. National CSIRTs publish this material openly, and they are a reasonable thing to subscribe to for the Member States you operate in. CERT Polska’s own explainer on the Regulation is a fair example of how these bodies are approaching it.

One caution about scope, because it affects how much of this to build around the Regulation specifically. The Cyber Resilience Act reaches products with digital elements, and Article 3 brings a hosted component into that definition only where the product cannot perform one of its functions without it and the component was designed by or under the responsibility of the same manufacturer. A good deal of finance software is delivered in ways that fall outside that test. The sensible conclusion is not to wait and see which of your vendors will be sending notices. It is to build the inventory and the response tiering so they work whatever the source, and treat the Article 14 flow as one high quality input among several.

An implementation checklist.

None of this requires a programme. Most of it is a handful of columns, one query on a schedule, and a set of decisions taken on a quiet afternoon rather than during an incident.

1. Write down the inbound channel before you need it. Article 14(8) says the manufacturer informs impacted users, and adds that a CSIRT may do so where the manufacturer does not. That means a notice can arrive by vendor portal, by email to whoever signed the contract, or from a national CSIRT. Name one monitored destination, tell your vendors to use it, and subscribe to the CSIRT feeds for the Member States you operate in.
2. Hold product identity the way a vendor advisory states it. Annex I Part II(4) obliges manufacturers to publish information allowing users to identify the affected product. That is a version string and usually a package or platform identifier, not the description on a purchase order. Store the identifiers alongside the commercial name so an advisory can be matched by query instead of by recognition.
3. Record what each product can reach, not only where it runs. The useful field is capability: can this thing release a payment, hold a bank credential, change a master record, submit a filing, post to the ledger, or only read. Everything about the speed and shape of your response follows from that one column.
4. Map each installation to legal entities and to bank relationships. A single middleware instance often serves several entities and several banks. When a notice arrives, the question asked in the first hour is which entities are exposed and which banking channels are touched, and that answer should be stored rather than reconstructed.
5. Decide the compensating controls in advance, per capability tier, and make them reversible. Lowering an auto-release threshold, requiring dual release, freezing bank detail changes or putting a filing behind a manual hold are all configuration changes finance already knows how to make. Deciding which ones apply, while nothing is happening, is far cheaper than deciding at 6pm on a Friday.
6. Give the response a ticket and a clock of your own. The Regulation puts 24 and 72 hour clocks on the manufacturer. Nothing puts one on you, so set your own service levels by capability tier and record the start time, the assessment, the action and the closure. That record is the control evidence.
7. Capture the support period end-date as a field now, even though Annex II(7) does not bite until 11 December 2027. Vendors are already publishing these dates ahead of the requirement. A dated column across the finance stack turns a scattered set of upgrade arguments into one sorted list.
8. Separate the security contact from the commercial contact in the vendor master. Article 13(17) and Annex II(2) will require vendors to give you one. Holding it in the same field as the account manager guarantees a notice reaches the person least able to act on it.
9. Join the inventory to whatever bills of materials you already collect. The bill of materials tells you what is inside a product. The Article 14 notice tells you when something inside it is being exploited. They join on component identifiers, and neither one is worth much without the other.
10. Include products you bought years ago. The Commission states plainly that the reporting obligations apply to products made available in the EU including those already on the market. The finance system nobody has touched since implementation is inside the scope of the notice you may receive about it.
11. Test the path with a drill rather than a document. Pick a real product in the highest capability tier, pretend a 72 hour notification has arrived, and time how long it takes to answer where it runs, which entities are affected, what it can do and what you would turn off. The gap between the plan and the clock is the finding.
12. Treat the machine-readable wording in Article 14(8) as an opportunity rather than a promise. It says where appropriate, so some notices will be prose. Build the matching step so a human can enter the same fields a feed would populate, and the automated path becomes an accelerator instead of a dependency.

Where this goes wrong, and how to see it coming.

The failure modes here are mostly ordinary, which is good news, because ordinary problems have ordinary fixes.

• Reading this as a security team problem and stopping there. Security owns the vulnerability. Finance owns the decision about whether the payment run goes out tonight, whether a bank channel stays open and whether a filing is held. Those decisions rest on facts about entities, bank relationships and authority limits that live in the finance systems, so a response process without finance in it stalls exactly where it matters.
• Assuming every vendor in the finance stack will send a CRA notice. The Regulation reaches products with digital elements, and Article 3 brings a remote data processing solution in only where the product cannot perform one of its functions without it and the solution was designed by or under the responsibility of the same manufacturer. Plenty of finance software is delivered in ways that sit outside that. Build the inventory so it is useful whatever the source of the notice.
• Keeping the inventory in a form that only a person can match. A list of product names in a spreadsheet cannot be joined to an advisory that identifies a component by its own identifier and version range. The matching step is where hours go, and it is the one part of this that is purely mechanical.
• Tiering by cost rather than by capability. The most expensive system in the finance stack is frequently a reporting layer that can do nothing but read. The riskiest is often a small, cheap connector that holds a bank credential. Sorting the response by licence value gets the order backwards.
• Treating the 24 hour early warning as the moment to act. Article 14(2)(a) makes the first notification deliberately thin, an early warning indicating where applicable the Member States concerned. The user-actionable content lands at 72 hours under Article 14(2)(b). Gearing the whole process to the first signal produces a lot of motion before there is anything to act on.
• Waiting for the patch when the control you need is a limit. Between a notification and a fix there can be days. Finance has levers that work in minutes: a lower auto-release threshold, dual release, a freeze on bank detail changes, a manual hold before transmission. Not reaching for them because the remediation plan says patch is a choice to carry the risk for the interval.
• Letting the response leave no trace. If a payment threshold was lowered for four days and then restored, that is a control that operated, and it belongs in the evidence record with the reason, the approver and the restoration. Handled informally, it looks in a later review like an unexplained configuration change.
• Forgetting to put the compensating control back. This is the most common operational failure with temporary controls of any kind. A threshold dropped during an incident and never restored quietly changes the shape of the payment process for everyone, and it is usually discovered by a complaint rather than by a review.
• Confusing the support period with a maintenance contract. Annex II(7) is about the end-date during which users can expect vulnerabilities to be handled and security updates to arrive. A product can be perfectly well supported commercially and still be past the point where its manufacturer commits to handling new vulnerabilities in it.
• Building the response around one named person. The notice can arrive at any hour, including into a European CSIRT feed on a day your team is not working. A rota and a shared destination are unglamorous and they are what make the clock survive a holiday.

Data and integration considerations.

• Product identity needs at least three fields, not one. The commercial name you buy under, the identifier a vendor advisory will use, and the version actually installed. Advisories state affected version ranges, so a version recorded as approximately current cannot be matched, and the assessment falls back to asking the vendor.
• Installation is a separate record from product. One product can run in several places, at different versions, under different configurations. The notice arrives against the product; the exposure belongs to the installation. Collapsing the two is what produces the answer that the company both does and does not run the affected version.
• Capability is the most valuable column and the one least often present. Model it as a small controlled set: payment initiation, credential custody, master data write, filing submission, ledger posting, read only. It drives the response tier, the service level and who has to be woken up.
• Legal entity and bank relationship belong on the installation. The first questions after a notice are which entities are exposed and which banking channels are involved. Both are joins that finance systems can already make, provided the inventory carries the entity and relationship keys rather than a free-text note about which business uses the system.
• The vendor security contact is a distinct field from the account manager, and both should carry a last-verified date. Article 13(17) will require the contact to exist. A contact captured once at implementation and never checked is a contact that has probably moved on.
• Support period end-date wants to be a date, held next to the source it came from. Annex II(7) makes it part of the information shipped with the product from 11 December 2027. Recording it as a date rather than as a sentence in a contract summary is what makes it sortable and reportable.
• Component identifiers carry across from the bill of materials. An advisory about a widely used library reaches you through the products that embed it, so the inventory should be able to answer which products contain a given component, not only which products you own. That is the join that makes a purchased dependency visible.
• The notification record is a first class object. Store the notice with its received timestamp, its source, the products and installations it matched, the assessment and who made it, the actions taken with their timestamps, and the restoration of any temporary control. That record is the difference between a response and a recollection.
• Temporary control changes need a start, an end and an owner. A threshold change made in response to a notice should be stored as a bounded change with a reason code that points back to the notification record, so the later question of why this limit moved has an answer that does not depend on anyone remembering.
• Keep the inventory history rather than only its current state. An auditor asking about an event six months ago needs to know what was installed then, not what is installed now. Versioned rows with effective dates cost very little and remove an entire category of unanswerable question.

What the evidence file should contain.

The reason to keep this material is not the Cyber Resilience Act, which asks nothing of a buyer. It is that responding to a vendor notice touches payment controls, master data controls and change management, all of which are already in scope for internal and external review. Handled as a control, the response produces evidence as a by-product.

• The inventory extract as it stood on the date a notification was received, showing the products, installations, versions, capability tiers, legal entities and banking relationships that the assessment was made against.
• The notification record itself: what arrived, from which source, at what time, and whether it came from the manufacturer under Article 14(8) or from a CSIRT acting where the manufacturer had not informed users.
• The matching result, showing which installations the notice was matched to and, just as importantly, the basis for concluding that other installations were not affected.
• The capability tier assigned to each affected installation and the service level that followed from it, so the speed of the response can be judged against a standard set in advance rather than against hindsight.
• Records of any compensating control applied, including the approval threshold or release rule changed, the value before and after, who approved it, when it took effect and when it was restored.
• For anything in the credential custody tier, evidence of the credential rotation decision, whether rotation was performed, and confirmation from the relevant bank or platform where a channel credential was replaced.
• The remediation record, linking the vendor security update to the change that deployed it, including the decision about whether the security update could be taken separately from functionality changes.
• Evidence that temporary controls were reversed, with the restoration date, so a review can see that the payment process returned to its approved configuration rather than drifting into a new one.
• The vendor communication trail, including the security contact used, what was asked and what the vendor confirmed about affected versions and exposure.
• Periodic evidence that the inventory is maintained: the review cadence, who performed it, what was added or retired, and the reconciliation to whatever software asset or procurement record the organisation treats as authoritative.

Questions worth asking before the first notice arrives.

• If an advisory named a component and a version range this afternoon, could we produce the list of affected installations by query, or would we start sending emails?
• Which systems in our finance stack can release a payment without a person, and do we have that written down anywhere other than in the memory of the people who built them?
• Where does a vendor security notice land today, and is that destination monitored on a day the primary owner is away?
• For each system that holds a bank or payment credential, how long does rotation take and who has to be involved?
• Can we lower an auto-release threshold or require dual release as a deliberate, reversible, evidenced action, or is that a change that would look indistinguishable from an unexplained configuration edit?
• Do we hold the security contact for each finance vendor separately from the commercial contact, and when was either last verified?
• Which of our finance systems are past, or close to, the end of the period during which their manufacturer will handle new vulnerabilities?
• If an auditor asked what was installed on a specific date six months ago, could we answer from records rather than from inference?
• When a temporary control was last applied anywhere in finance, was it recorded, and can we show when it was put back?
• Which entities and banking relationships would be in scope if our payment connectivity middleware were named in a notice tomorrow?

A better signal is worth meeting halfway.

The interesting thing about Article 14 is not the obligation. It is that a large body of information which used to travel by newsletter and word of mouth now travels on a legal clock, through a single platform, with a duty attached to pass it to the people running the software, and with an explicit preference for a format a machine can read. For a finance function that depends on a long tail of connectors, engines and agents nobody thinks of as products, that is a meaningful improvement in the weather.

The work it asks for on your side is modest and it pays for itself elsewhere. An inventory keyed to installations rather than products, carrying exact versions and the identifiers vendors actually publish, is the same artefact that answers a due diligence questionnaire, an insurance renewal and an auditor’s question about the IT environment. A capability column that records what each system is allowed to do is the same thing a segregation of duties review needs. A set of agreed, reversible levers for the payment run is useful during any operational disruption, not only a security one.

Start with one query rather than a programme. Take the list of finance systems you already have, add a column for what each one can do, and sort it. The rows at the top, the things that can move money or hold a credential that can, are a short list in most organisations. Get exact versions and vendor security contacts for those, decide the lever for each, and the hardest part is finished. Everything after that is a monthly query and a habit.

Sources

• Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (the Cyber Resilience Act), consolidated text on EUR-Lex. Downloaded and read directly rather than through a fetched summary. Source for every normative statement in this article: the definitions of a product with digital elements, remote data processing and an actively exploited vulnerability in Article 3; the manufacturer obligations and the support period criteria in Article 13, including the single point of contact in Article 13(17); the reporting obligations, deadlines and the duty to inform impacted users in Article 14(1), 14(2), 14(5), 14(7) and 14(8); the penalties in Article 64(2); the application dates in Article 71(2); the vulnerability handling requirements in Annex I Part II; and the information and instructions to the user in Annex II.
• ENISA news item, The CRA Single Reporting Platform is launched, 11 September 2026. Read directly. Source for the statement that ENISA has deployed the initial operating capability of the Single Reporting Platform, that it allows a manufacturer to report once and have the information reach all appropriate authorities, that the receiving CSIRT disseminates to other Member States where the product is available while ENISA has simultaneous access, and that ENISA will continue to expand the platform based on operational experience.
• European Commission, Cyber Resilience Act, Reporting obligations, on the Shaping Europe’s digital future portal. Read directly. Source for the confirmation that the reporting obligations started on 11 September 2026, that reporting for open source software stewards under Article 24(3) starts on 11 December 2027, that the Single Reporting Platform is operational as of 11 September 2026, and that the Commission adopted a delegated act on 11 December 2025 on the grounds for a CSIRT delaying dissemination.
• European Commission news article, Safer and more secure digital products, 11 September 2026. Read directly. Source for the point that matters most to a buyer and is easy to miss elsewhere: the reporting obligations apply to all products with digital elements made available in the EU, including those already on the market.
• European Commission, Commission publishes new guidance to support timely Cyber Resilience Act implementation, library entry for the guidance approved on 27 July 2026 under reference C(2026) 5252. Cited for its existence and subject matter only. The document itself could not be retrieved at the time of writing, because the Commission newsroom document endpoint returned a server error page rather than the file, so nothing in this article rests on its contents.
• Hogan Lovells, EU Cyber Resilience Act: Preparing for Vulnerability and Incident Reporting. Practitioner analysis, used for corroboration of the staged 24 hour, 72 hour and 14 day structure and as background on how counsel are describing the obligation to manufacturers. Not used as the basis for any requirement stated here.
• Crowell & Moring, EU Cyber Resilience Act: the 11 September 2026 incident and vulnerability reporting deadline. Practitioner client alert, used for corroboration of the reporting timetable and for general background on readiness expectations ahead of the date.
• CERT Polska, CRA, nowe obowiązki dla producentów oprogramowania i korzyści dla użytkowników. A national CSIRT’s own explainer on the Regulation, cited as an example of the kind of body that receives these notifications and that may pass information to users under Article 14(8).

A note on how this was researched. Every statement about what the Cyber Resilience Act requires comes from the text of Regulation (EU) 2024/2847 itself, downloaded from EUR-Lex and read directly rather than through a fetched summary. That covers the definitions in Article 3, the manufacturer obligations and support period criteria in Article 13, the reporting duties and deadlines and the duty to inform users in Article 14, the penalties in Article 64(2), the application dates in Article 71(2), the vulnerability handling requirements in Annex I Part II and the information to users in Annex II. The start date and the launch of the Single Reporting Platform were confirmed against ENISA’s own announcement and the Commission’s reporting obligations page, and the point that the duty covers products already on the market comes from the Commission’s news article of 11 September 2026. The Commission’s guidance approved on 27 July 2026 under reference C(2026) 5252 is listed for completeness, but the document endpoint returned a server error rather than the file when this was written, so nothing here rests on its contents. Practitioner sources are attributed as practitioner analysis and used for corroboration and background, never as the basis for a requirement. Two public posts on X are cited, each opened and verified as live, public and attributed to the account that published it. The inventory record and the capability tiering in this article are worked illustrations of structure; the vendor names, identifiers, thresholds and timings in them are placeholders and describe no real organisation or product. Nothing here is legal or security advice for a specific organisation, and the obligations that apply to any manufacturer come from the Regulation rather than from this article.