The EU Cyber Resilience Act is the most ambitious piece of product cybersecurity legislation written anywhere in the last decade. It reaches virtually every product with digital elements sold into the European Union, it places hard obligations on manufacturers across the entire product lifecycle, and its conformity assessment requirements are not optional suggestions. By the time the core obligations become fully enforceable in December 2027, any vendor that ships into Europe will need to demonstrate, on request, that their products meet the essential cybersecurity requirements set out in Annex I and that they handle vulnerabilities in line with Annex I Part II.
This is where the two categories of AI security tooling we have been tracking diverge sharply. Griffin AI, the compliance-aware agent inside Safeguard, is designed around the artifact shapes the CRA actually wants. Mythos-class pure-LLM tools, which rely entirely on free-form language model output, can discuss the CRA eloquently but struggle to produce the documentation a notified body, a market surveillance authority, or an enterprise customer's procurement team actually requires.
What the CRA obligates
Annex I Part I covers the essential requirements for cybersecurity properties of the product itself: secure-by-default configuration, protection against unauthorized access, confidentiality and integrity of data, minimization of attack surfaces, and related items. Annex I Part II covers how the manufacturer handles vulnerabilities across the product lifecycle: identifying and documenting components, addressing and remediating vulnerabilities without delay, applying effective testing, publishing information about fixed vulnerabilities, coordinating disclosure, and providing security updates in a timely manner.
Underneath these sit the technical documentation obligations of Article 31 and Annex VII. The manufacturer must maintain documentation describing the product, the assessment of cybersecurity risks, and the design, development, and production choices made in response. Article 13 carries through the vulnerability handling expectations and requires, among other things, that the manufacturer draw up an SBOM in a commonly used, machine-readable format for internal use, and produce it to a competent authority on reasoned request.
None of this is satisfied by answering questions. It is satisfied by producing, maintaining, and being able to surface documents.
Griffin AI's artifact-first model
Griffin AI treats every finding, policy decision, and remediation action as a persisted, structured record that is explicitly linkable to CRA obligations. When Safeguard ingests a repository or an SBOM, Griffin creates a component inventory that is CRA-aligned by construction. Each component carries its identifier, version, supplier, license, provenance, and vulnerability state. That inventory is exportable in SPDX and CycloneDX formats, which directly satisfies the machine-readable SBOM requirement under Article 13.
Vulnerability handling follows the same pattern. When a new advisory appears that affects a shipped product, Griffin creates a finding that is tied to the component, the affected product version, and the deployment context. The finding carries a severity, a reachability judgment, a suggested remediation, and a handling state. The handling state transitions are logged with timestamps, operator identity, and policy version. That log is exactly the kind of artifact Annex I Part II expects.
The technical documentation obligations under Annex VII benefit from the same architecture. The product risk assessment, the mitigation rationale, the test evidence, and the ongoing monitoring records all live inside Safeguard as structured documents with export paths. When a customer under the product's legal umbrella requests the CRA technical file, the vendor pulls a bundle; they do not reconstruct one.
Mythos-class tools and the documentation gap
A Mythos-class tool is excellent at summarizing a codebase, identifying risky patterns, and explaining them in natural language. These are valuable capabilities. They are not, however, the capabilities that the CRA tests.
Consider Article 13's SBOM requirement. A market surveillance authority under Article 54 can request the SBOM on a reasoned basis, and the manufacturer must produce it. A pure-LLM tool can be asked, "what components are in this product?" and it will list many of them. It will not produce a cryptographically stable, machine-readable SPDX or CycloneDX document that matches what was actually shipped at a specific version on a specific date. That document either exists or it does not, and a model's reasoning is not a substitute.
The same gap appears in vulnerability handling. Annex I Part II, paragraph 2, requires the manufacturer to address and remediate vulnerabilities without delay. Regulators will ask how that obligation is operationally met: what triggered the awareness of the vulnerability, when it was triggered, who evaluated it, what decision was made, when the fix shipped, and how affected users were informed. Each of those answers wants a record, not a narrative. Griffin produces those records as a consequence of the normal workflow. Mythos-class tools do not persist them.
Coordinated disclosure and the support period
Two CRA obligations tend to catch vendors off guard. The first is the expectation that vulnerability handling includes coordinated disclosure processes, including the handling of reports from third parties. The second is the support period: the CRA expects manufacturers to provide security updates for a time period proportionate to the expected use of the product, which is normally at least five years for products with digital elements that are not obviously short-lived.
Both obligations push vendors toward operating a well-documented vulnerability program over years, not weeks. Griffin AI's persistent case model is built for exactly this timeframe. A disclosure report becomes a case. The case carries external reporter identity, communications, triage, reproduction, fix, release, and advisory publication. Five years from now, the case is still retrievable, still signed, and still tied to a product version.
A Mythos-class tool, by contrast, has no durable case model. Conversations are ephemeral. The facts they reasoned over today may not be the facts they reason over next month after a model update. You would not run a five-year vulnerability program that way, and CRA regulators will not accept a program that lacks a case record.
Conformity assessment and the notified body
Most CRA products will go through a self-assessment route, but "important" and "critical" products face third-party conformity assessment by a notified body. In both cases, the assessor wants consistent, traceable evidence. Self-assessment is not lighter work than third-party assessment; it simply shifts the burden onto the manufacturer to maintain the documentation themselves.
Griffin AI's CRA readiness report mirrors the structure an assessor expects. It enumerates the essential requirements from Annex I Part I, lists the controls in place that address each, points to the policy that enforces each control, and links to the last N decisions the policy emitted. It does the same for Part II vulnerability handling obligations. The entire report is exportable as a bundle.
Mythos-class tools, lacking that structure, typically produce either a prose document that is internally inconsistent with operational reality or a checklist that says "yes" without evidence. Neither survives an assessor's follow-up questions.
The practical recommendation
Every serious EU-facing vendor should be building toward CRA readiness now. The closer the enforcement dates get, the more expensive it becomes to reconstruct evidence that should have been captured continuously. Griffin AI is built to make that continuous capture a by-product of ordinary development work. Mythos-class pure-LLM tools are built to answer questions. Both are useful. Only one of them will stand up to an Annex VII technical file review. When a notified body or a market surveillance authority eventually asks, you want to hand them a document, not a conversation.