Subscribe
Share
Share
Embed
Daily analysis of AI liability, regulatory enforcement, and governance strategy for the C-Suite. Hosted by Shelton Hill, AI Governance & Litigation Preparedness Consultant. We bridge the gap between technical models and legal defense.
innovation moves at the speed of code
liability moves at the speed of law
welcome to the AI Governance Brief
we bridge the gap between technical models
and legal defense here is your host
litigation preparedness consultant Keith Hill
last month I conducted a complimentary CRA
readiness assessment for a midsize
medical technology company
their compliance team was confident
they had three products requiring CRA attention
when we completed the inventory exercise
we identified 23
twenty of those products had no documented compliance
owner 12 had never undergone security assessment
and four fell into important class 2
requiring third party conformity
assessment from notified bodies
already signalling capacity constraints
their 18 month compliance timeline
just became a resource crisis
this is the AI Governance brief and this is Keith
and today
we're continuing with Episode 2 of the CRA countdown
in episode 1
we established why September 2026 is the real deadline
and why organizations
planning for December 2027 are already behind
today
we confront the question that determines everything
else in your compliance journey
what exactly is the scope
the CRA applies to products with digital elements
that phrase sounds straightforward
until you start examining your actual product portfolio
connected medical devices
cloud enabled monitoring platforms
APIs your customers integrate into their own systems
firmware embedded into hardware
you haven't updated in three years
legacy software still generating revenue
but built before anyone considered security by design
by the end of this episode
you'll understand exactly how the CRA defines scope
how the four
tiered classification system
determines your compliance pathway
and how to conduct a product inventory
that captures everything
including the products hiding in plain sight
let's start with what the regulation actually says
Article 3 of the Cyber Resilience Act
defines a product with digital elements
as any software or hardware product
and its remote data processing solutions
including software or hardware components
being placed on the market separately
listen carefully to that definition
it encompasses three distinct product categories
that most organizations analyze separately
first software products
any application platform
or software service
your organization places on the EU market
this includes on premise software
SAS platforms accessible by EU customers
mobile applications available in EU app stores
and development tools or SDKs you distribute
second
hardware products with embedded software or firmware
medical devices with digital interfaces
industrial equipment with connected sensors
consumer electronics with software components
if it contains code and you sell it in the EU
it's likely in scope
third and this is where scope surprises emerge
remote data Processing solutions
the CRA explicitly captures cloud back ends
data processing services and remote functionality
essential to product operation
if your connected
device depends on cloud infrastructure to function
that infrastructure is part of the product
you cannot claim your hardware is compliant
while your essential cloud services are not
the CRA doesn't care how you've organized
your product portfolio internally
it cares about what you place on the EU market
and what that product requires to function
here's where midsize organizations
consistently underestimate scope
you may have a core product line that generates
the majority of your revenue
your compliance planning focus is there
but what about the monitoring dashboard
you provide to your customers
what about the integration APIs
that connect your product to third party systems
what about the mobile companion app
that most customers never use
but remains available in EU app stores
each of these may constitute a separate product
with digital elements
requiring independent CRA compliance
and if you haven't inventoried them
you haven't started compliance
the scope question becomes even more complex
when you consider what the CRA excludes
medical devices already certified under MDR or IVDR
are exempt from CRA product requirements
they follow their own cybersecurity provisions
motor vehicles
covered by type approval regulations are exempt
products exclusively for national security
or military purpose are exempt
open source software
developed outside commercial activity is also exempt
but these exemptions are narrower
than many organizations assume
your MDR certified infusion pump may not be exempt
the patent data management platform that
receives data from that pump
is not exempt your clinical decision support software
built on open source framework
is not exempt
simply because it incorporates open source components
the exemption applies to non commercial
open source development itself
not to commercial products
that happen to use open source dependencies
exemption analysis that starts with the answer you want
we're probably exempt
produces compliance gaps that regulators will find
the scope confusion I observe most frequently
stems from organizational structure
not regulatory complexity
products are managed by different business units
engineering teams maintain legacy systems
that product management no longer tracks
cloud infrastructure is owned by it
but supports customer facing products
owned by product teams
when I ask what product does your organization
place on the EU market I'm often asking a question
that no single person or function can answer
let me describe three specific gap patterns
the first is the legacy product gap
your organization built a software platform
eight years ago it still has active customers
it still generates revenue
but active development ceased four years ago
product management considers it in maintenance mode
engineering allocates minimal resources
when I ask whether this product is in CRA scope
the typical response is uncertainty
because no one has evaluated legacy products
through this lens
here's what the CRA says
manufacturers must ensure conformity
during the product support period
which must be at least five years from the market
placement or expected product lifetime
whichever is shorter if you have customers actively
using your legacy product
you are likely still within the support period
if you're still placing that product on the market
even just processing renewals
you're still the manufacturer with CRA obligations
the product you've forgotten about
hasn't forgotten about you
the second gap is the component product gap
your organization develops an API that customers
integrate into their own systems
or an SDK that developers use to build applications
or software library
distributed through package managers
these are products with digital elements
they have compliance obligations
but because they're components
rather than end user products
they often escape product level governance
the implementing regulation EU 2 0
2 5 slash 2
3 9
2 published in January 2025
provides crucial clarification here
it confirms that when a component falls into important
class 1 or higher the final product
integrating that component
does not automatically
inherit the higher classification
the component
has its own classification and conformity requirements
the integrated product is assessed independently
this clarification reduces some compliance burden for
integrators
but it doesn't eliminate the component manufacturer's
obligations if you produce components libraries APIs
STKs you must classify and comply for those components
independently
the third gap is the cloud infrastructure gap
modern products rarely operate in isolation
your connected device transmits data to cloud services
your mobile application depends on back end APIs
your desktop software validates licenses
against cloud infrastructure
under CRA Article 3
these remote data processing solutions
are part of the product when I ask organizations
about their cloud infrastructure
compliance posture
I often hear that's it's responsibility or we use AWS
so Amazon handles security
neither response addresses CRA obligations
you are the manufacturer the cloud services
essential to your product's operation
are your compliance responsibility
regardless of who hosts the infrastructure
you cannot outsource compliance
responsibility to your cloud provider
you can only outsource infrastructure
the regulatory obligation remains yours
let me explain exactly why
scope underestimation
creates personal liability for executives
the CRA establishes that manufacturers bear
responsibility
for placing compliant products on the EU market
Article 13 requires manufacturers to exercise
due diligence when assessing conformity
market surveillance authorities
national regulatory bodies in each EU member state
have the authority to investigate compliance
request documentation and impose penalties
when a market surveillance
authority examines your compliance posture
they won't limit their review to products
you've identified
they'll ask what process you use to determine scope
they'll ask how you ensure that new products
are captured
they'll ask who owns the scope determination
and how frequently it's reviewed
if your process failed to identify products
that clearly fall within CRA definition
you have a governance gap
and governance gaps create liability
that flows upward to executive leadership
consider this enforcement scenario
a security researcher discloses a vulnerability
affecting an API component
your organization distributes
under September 2026
vulnerability reporting requirements
you must notify ENISA within 24 hours
but your API wasn't in your product inventory
you didn't have SBO m coverage
you didn't know which customers were affected
your 24 hour timeline passed
while you were still conducting manual assessment
when enforcement authorities investigate
they discover that your CRA
scope determination excluded APIs
and developer tools they discovered that engineering
leadership flagged those products
12 months earlier but compliance deferred inclusion
pending further analysis
they discovered meeting minutes
emails and Slack messages
documenting awareness of the gap
documentation of scope decisions you made
become evidence in enforcement proceedings
document carefully or document not at all
the product liability directive
presumption of defectiveness I discussed in Episode 1
applies here directly
if your product wasn't CRA compliant
because you incorrectly determined it wasn't in scope
courts can presume defectiveness
plaintiff attorneys will depose the executives
who approved the scope determination methodology
they'll ask what expertise was involved
they'll ask what legal guidance was obtained
they'll ask why obvious products were excluded
for CEOs and board members
scope determination is not a technical decision
you can delegate with oversight
it's a governance decision
that defines your organization's compliance boundary
the executives who treat
scope as a box for engineering to check
are the executives who face personal exposure
when that boundary proves inadequate
the good news is that comprehensive
scope determination is achievable
it requires methodology
cross functional input and documented decisions
but it doesn't require new technology
or massive resource investment
here's the framework I recommend
for midsized organizations
start with revenue streams
your finance function knows what products
generate revenue start there
pull a complete list of skews
and service offerings that generated EU source revenue
in the past 24 months
this catches active commercial products
that product management might overlook
follow the money revenue data
captures products that organizational memory forgets
next expand through technical architecture
your engineering function maintains systems diagrams
repository list and infrastructure documentation
walk through these systematically
what software do you build and distribute
what hardware do you manufacture or assemble
what cloud services do you operate
that support customer facing products
what components do you distribute
through package managers app stores or direct download
third examine customer relationships
your customer success function
knows what customers actually use
pull support ticket data
usage analytics and customer communication records
are customers using products
that aren't in your initial inventory
are their legacy systems still actively supported
are there custom implementations
that might constitute separate products
fourth review development activity
your engineering function maintains code repositories
audit repository access
and commit activity over the past 24 months
what code bases are actively maintained
what code bases receive security patches
but no feature development
what code bases have been dormant
but could potentially be reactivated
fifth and this is critical
challenge exemption assumptions
for every product initially categorized as exempt
document the specific regulatory basis for exemption
MDR certified medical device document
the MDR Certificate number and scope
National Security product document
the specific customer and use case
non commercial open source document
how the product avoids commercial activity
when you have completed this process
you should have a comprehensive product inventory
with three categories clearly in scope
clearly exempt and requiring further analysis
for the requiring further analysis
category air towards inclusion
the regulatory cost of false negatives
products you incorrectly excluded
far exceeds the compliance cost of false positives
now you're ready for classification
the CRA establishes four product tiers
with different conformity assessment requirements
understanding these tiers is essential
because classification determines your compliance
pathway your timeline and your resource requirements
the default category covers products
that don't fall into the other three categories
European Commission estimates
suggest approximately 90% of products will be default
category these products can use
internal conformity assessment procedures
under Annex 8 Module a
essentially
self certification with proper documentation
no third party involvement required
though you must still meet all essential requirements
important class 1 products are listed in Annex 3
part 1 these include identity management systems
password managers VPN software
network management tools
s I E
m systems
boot managers public key infrastructure software
and physical network interfaces
for these products
manufacturers can use internal assessment
if they apply harmonized standards
covering all essential requirements
if harmonized standards don't exist
or aren't fully applied
third party assessment becomes mandatory
important class 2 products are listed in Annex 3
part 2 these include operating systems hypervisors
container runtimes firewalls
intrusion detection systems
microprocessors with security features
hardware security modules
crypto processors smart card readers
and industrial control system products
these products
require mandatory third party conformity assessment
by a notified body
critical products are listed in Annex 4
and face the highest scrutiny
these include hardware devices with security boxes
smart meter gateways and specific product types
that the European Commission can add through delegated
acts
critical products also require third party assessment
with additional cybersecurity certification
requirements
here's why classification matters for your planning
if all your products are default category
your conformity assessment is primarily documentation
and evidence generation
demanding but achievable with internal resources
if you have important class 2 or critical products
you must engage notified bodies
for third party assessment
and notified bodies have a finite capacity
and a finite schedule
which is why I make the argument
that most companies are late for the CRA countdown
The European
Commission is still designating notified bodies
under the CRA framework as of early 2025
the infrastructure for third party assessment
is still maturing
organizations with important class 2 products
should begin engaging potential notified bodies now
not to begin formal assessment
but to understand capacity
timelines and requirements
the organizations that wait until late 2026
will discover that preferred
assessment bodies are fully booked
classification isn't just a compliance exercise
it's a resource planning exercise
the conformity assessment pathway you face
determines the expertise timeline and budget you need
let me share a classification scenario
I encounter frequently
when talking to people about how they're preparing
for this countdown a healthcare technology company
produces a patient monitoring platform
the core monitoring software
collects and displays patient data
likely default category if it doesn't perform identity
management or security functions
but the platform includes a single sign on module
that manages healthcare provider authentication
identity management systems are important class 1
under Annex 3
does the SSO module evaluate the entire platform
the implementing Regulation 2 0
2 5 slash 2
3 9
2 clarifies that
component classification doesn't automatically elevate
integrated product classification
the SSO module must meet important class 1 requirements
the broader platform is assessed independently
based on its own functionality
this is good news for the manufacturer
but only if they've identified the SSO module
as a separately classified component
requiring its own conformity evidence
organizations
that have completed comprehensive scope determination
and classification report consistent benefits
beyond mere compliance first
they identify security gaps
before regulators do the product inventory process
surfaces forgotten systems
undocumented dependencies and ownership ambiguities
one financial services firm I'm aware of
discovered during inventory
that a payment processing API
generating significant transaction volume
had no documented security owner
and hadn't
received a security assessment in four years
they identified this through CRA preparation
market surveillance authorities
would have identified it through enforcement
second they make informed resource allocation decisions
when you know you have three important class 2 products
requiring third party assessment
you can budget for notified body engagement
when you know you have 47 default category products
you can plan documentation and evidence generation
resources accordingly when you don't know what you have
you are either under investing or over investing
and neither is optimal third
they reduce MNA integration risk
organizations with mature product governance
can assess acquisition targets
against CRA requirements during due diligence
one private equity firm now requires
CRA scope assessment as part of standard due diligence
for EU market targets they've identified compliance
liabilities that affected deal
valuation and integration planning
the organization that knows its product portfolio
can govern its product portfolio
the organization that doesn't is governing blind
fourth early classifiers are securing
notified body relationships
the conformity assessment body
ecosystem under CRA is still developing
organizations
engaging early are establishing relationships
understanding assessment methodologies
and reserving capacity by late 2026
these organizations will be in assessment
late comers will be waiting in line
let me give you a specific 14 day action plan
for scope determination and preliminary classification
days one through 3 revenue based product identification
work with finance to pull every product
skew and service
offering that generated EU sourced income
in the past 24 months
this creates your initial inventory baseline
days 4 through 6 technical architecture expansion
work with engineering to identify software applications
hardware products cloud services
and components not captured in revenue data
review
code repositories for active and maintenance mode
projects review
infrastructure
documentation for customer facing cloud services
days 7 through 9 Customer Relationship validation
work with customer success to identify products
actively supported products
with active user bases
and legacy products still receiving maintenance
cross reference against your inventory to identify gaps
days 10 through 12 exemption analysis
for every product you believe as exempt
document the Specific Regulatory Basis
MDR device document certification number
National Security document
the customer and use case challenge assumptions
if the exemption basis is unclear
categorize as in scope pending further analysis
days 13 and 14 preliminary classification
using Annex 3 and Annex 4 criteria
classify each in scope product as default
important class 1 important class 2
or critical flag uncertain classifications
for deeper analysis
for any product classifications as important
class 2 or critical
begin researching notified body capacity and timelines
at the end of 14 days you have three deliverables
a comprehensive product inventory
an exemption register with documented rationale
and a preliminary classification matrix
these deliverables enable informed conversations
about resource requirements
timeline feasibility and executive oversight structure
in Episode 3 we'll dig into the technical requirements
that make compliance professionals nervous
the 21 Essential Cybersecurity Requirements in Annex 1
what SBO m compliance actually requires
and how Devsecops
integration addresses most requirements
without new tool purchases
it's always good to save money
here's what I want you to carry from this episode
you cannot comply with requirements
you haven't mapped to specific products
and you cannot delegate what you haven't defined
scope determination is not a preliminary
administrative task
it's the foundation that everything else builds upon
classification determines your conformity
assessment pathway
conformity assessment pathway determines your timeline
and resource requirements
get scope wrong and every downstream decision
is built on a false premise
most midsize organizations
underestimate product scope by 60 to 70%
on initial assessment
they forget legacy products still generating revenue
they exclude APIs and developer tools
they assume cloud infrastructure
is someone else's problem
they accept exemption assumptions
without rigorous analysis
market surveillance authorities will
not share these blind spots
when enforcement begins
regulators will ask what process
you use to determine scope
they'll examine
whether the process was designed to capture products
or designed to minimize compliance burdens
the documentation trail you create today
becomes evidence tomorrow
the 14 day action plan in this episode
generates the clarity your organization needs
execute it present the results to your executive team
start the conversation about what you actually have
and what compliance requires
in the next episode
we'll examine the technical requirements
nobody understands
we'll decode Annex One's 21 essential requirements
explain what sob compliance actually demands
and show how mature death sec
ops practices
address the majority of technical obligations
this has been Keith with the AI Governance brief
and if you need help putting this all together
or you wanna have a conversation and sort of
get your ideas in order and how you wanna move forward
I'm always available and if you like the episode
or you'd like to hear about something else specific
let me know down in the comments
always glad to help once again
this is Keith with the AI Governance brief
have a wonderful day
that's the brief for today
remember if you can't explain your governance
to a jury in plain English
you don't have governance
you have exposure don't wait for the deposition
book a first witness
stress test for your compliance team
at verbal
alchemist at Gmail dot com
this is Keith and I'll see you tomorrow