How to Meet EU Cyber Resilience Act Requirements with StackHawk’s Pre-Production Testing

The EU Cyber Resilience Act (CRA) entered into force December 10, 2024, with full obligations applying from December 11, 2027. Security is now a legal requirement for all products with digital elements sold in the EU market. The CRA introduces mandatory cybersecurity throughout the entire product lifecycle, from design to end-of-life. Potential fines reach €15 million or 2.5% of global annual turnover for non-compliance.

For application security, the CRA requires products to be delivered with “no known exploitable vulnerabilities.” Organizations must handle vulnerabilities throughout the product lifecycle with documented processes. You need proof, not promises.

StackHawk’s pre-production testing proves compliance. Shift-left DAST finds real vulnerabilities before products reach the market. Automated API discovery ensures complete attack surface coverage—no shadow APIs—and helps with documentation requirements. CI/CD-native testing creates the continuous testing evidence the CRA requires. Developer-friendly workflows ensure vulnerabilities get fixed, not just documented.

Understanding the EU Cyber Resilience Act

Scope: Products with Digital Elements (PDEs)

The CRA covers any hardware or software product with direct or indirect network or device connectivity. This includes SaaS applications, APIs, microservices, IoT devices, and embedded software. Products are in scope even if they never actually connect. If they could connect, they’re covered.

Key exemption: Pure SaaS offerings are excluded, but the APIs powering them may not be.

Three Product Classifications with Different Requirements

• Default (Class I): Most products, self-assessment conformity is acceptable
• Important (Class II): Higher risk products, may require third-party assessment
• Critical: Highest risk, mandatory third-party evaluation and stricter oversight

Key CRA Requirements for Software Organizations

Essential Cybersecurity Requirements (Annex I)

Part 1: Security by Design and Default

• Appropriate cybersecurity measures based on product risk
• Secure configuration as default state
• Protection of data confidentiality and integrity
• Minimize attack surface and limit privileges

Part 2: Vulnerability Handling

• Identify and document all product components and vulnerabilities
• Address vulnerabilities without delay
• Provide automatic security updates
• Create comprehensive vulnerability-handling plan
• Regular testing and security review throughout support period

Documentation and Conformity Assessment

• Technical documentation proving security measures were implemented
• Evidence of security testing throughout development
• 10-year retention requirement for all product security documentation
• CE marking for products demonstrating compliance

Incident and Vulnerability Reporting (Starting September 11, 2026)

• Report actively exploited vulnerabilities to CSIRT coordinators and ENISA
• 24-hour initial alert, 72-hour detailed report, 14-day final report
• Must maintain incident reporting capabilities throughout product support period

CRA Timeline: Critical Dates

• December 10, 2024: CRA entered into force
• September 11, 2026: Incident/vulnerability reporting obligations begin
• December 11, 2027: Main CRA obligations apply and non-compliant products cannot be sold in EU
• 36-month transition period for existing products (unless substantial modification occurs)

How StackHawk Addresses CRA Requirements

1. Pre-Production Security Testing: Proving “Secure by Design”

CRA Requirement: Annex I, Part 1 mandates that products must be “designed, developed, and produced to ensure appropriate cybersecurity.” Organizations must implement security measures throughout the development lifecycle. Technical documentation must demonstrate security was built-in, not bolted-on.

The challenge: The CRA requires “no known exploitable vulnerabilities” at market release. You need to validate actual security, not theoretical code patterns.

How StackHawk finds real exploitable vulnerabilities:

StackHawk tests running applications with real HTTP requests. It validates actual authentication flows and confirms vulnerabilities are truly exploitable. This provides confidence to certify products are secure through realistic testing conditions, not just static code analysis that flags patterns.

Runtime testing in CI/CD validates security before market release. StackHawk runs DAST directly in CI/CD pipelines—GitHub Actions, GitLab CI, Jenkins, CircleCI. It tests every build before code reaches production. Unlike SAST (which checks syntax) or production DAST (which tests post-release), StackHawk validates security at runtime in pre-production. This catches and enables fixing issues before they become market-ready products.

How StackHawk creates audit-ready evidence:

Every scan generates detailed documentation: what was tested and when, plus what findings emerged. As findings are triaged, StackHawk tracks their status, whether they’ve been assigned to a developer, marked as risk accepted, or flagged as a false positive. When subsequent scans show a finding has been resolved, it drops off the results, giving teams a clear before-and-after view of their security posture over time. This directly supports the CRA’s technical documentation requirements and proves continuous testing throughout development, not just once before launch.

Security validation integrates into developer workflows. Developers receive findings in existing tools—Jira, Slack, IDE plugins. Code-level context shows exactly where vulnerabilities exist and how to fix them. CRA compliance becomes embedded in normal development, not a separate security process. This ensures vulnerabilities get fixed as part of standard workflow.

The compliance benefit:

StackHawk’s pre-production testing directly demonstrates “secure by design” principles. You’re not retrofitting security into finished products but validating security at every build. This creates the documented evidence the CRA requires while maintaining development velocity. It proves security was built in, not bolted on after the fact.

2. Complete API Attack Surface Visibility: No Shadow APIs

CRA Requirement: Annex I, Part 2 requires organizations to “identify and document the PDE components and their vulnerabilities.” You must maintain a complete inventory of all digital product elements. Technical documentation must demonstrate comprehensive understanding of attack surface.

The challenge: You can’t secure or document APIs you don’t know exist. Shadow APIs and undocumented endpoints create compliance gaps. Manual inventory processes always miss something.

How StackHawk discovers complete attack surface:

StackHawk discovers the complete API attack surface by analyzing source code and runtime behavior. It finds REST, GraphQL, gRPC, and SOAP endpoints automatically. This includes internal microservice APIs, deprecated endpoints still in code, and shadow APIs. If code exists, StackHawk finds it, eliminating manual discovery gaps.

It auto-generates OpenAPI specifications to enable testing. The CRA requires testing what exists, but manual spec creation is always incomplete. StackHawk automatically generates accurate, current API specifications from discovered endpoints. This eliminates the manual spec maintenance bottleneck that causes testing gaps and ensures every API endpoint gets security testing coverage.

Attack surface coverage scales as applications evolve. StackHawk continuously discovers new endpoints as code changes and automatically incorporates new APIs into testing coverage. Shadow APIs become impossible because API discovery happens with every build. This maintains complete visibility in AI-accelerated development environments where new code appears constantly.

How StackHawk supports documentation requirements:

StackHawk creates a comprehensive application inventory for documentation. You get clear visibility into your complete digital product portfolio: which applications exist, what APIs they expose, which protocols are used, and how components connect. This directly supports the CRA’s component documentation requirements and provides the foundation for comprehensive vulnerability management.

The compliance benefit:

CRA compliance requires documenting and securing everything with digital elements. StackHawk’s automatic discovery ensures you can’t miss APIs or overlook microservices. It maintains the complete attack surface visibility the regulation demands. Shadow APIs become impossible when discovery happens automatically with every build.

3. Continuous Vulnerability Management: Finding and Fixing at Speed

CRA Requirement: Annex I, Part 2 mandates that organizations “address vulnerabilities without delay.” This requires regular testing and review throughout the product support period, a comprehensive vulnerability-handling plan, and automatic security updates for fixing vulnerabilities promptly.

The challenge: “Without delay” requires tools that find issues fast and enable rapid fixing. Legacy security testing creates weeks-long cycles. Modern development velocity demands faster vulnerability detection and remediation.

How StackHawk enables continuous vulnerability detection:

CI/CD-native testing runs in pipelines, testing every code change. This creates a continuous feedback loop where vulnerabilities are caught immediately. Tests execute in minutes with real-time results. Developers get findings while still working on the code, not weeks later in a security report.

StackHawk provides comprehensive OWASP coverage for modern application risks. It tests all OWASP Top 10 vulnerabilities, covers the OWASP API Security Top 10 for API-specific risks, and also addresses the OWASP LLM Top 10 for applications integrating large language models. It finds complex business logic flaws: broken authentication, authorization bypasses, session management issues. This tests security “appropriate to the risks” products face per CRA requirements.

How StackHawk drives rapid remediation:

Developer-friendly results include code-level context showing exactly where vulnerabilities exist, step-by-step remediation guidance, integration into developer tools (Jira, Slack, IDEs), and fix verification testing that confirms remediation worked. This delivers actionable information in workflow, not security reports requiring translation.

Quality gates enforce security standards in pipelines. You can fail builds when critical vulnerabilities are detected, creating enforceable security checkpoints aligned with your vulnerability handling plan. This ensures no product ships with “known exploitable vulnerabilities”—meeting the CRA’s core security requirement at the deployment gate.

How StackHawk maintains compliance throughout product lifecycle:

The CRA requires testing throughout the support period, not just before initial release. Testing continues automatically with every code update, maintenance patch, and security fix. Continuous testing is built into how you maintain products—no separate process required for ongoing compliance.

The compliance benefit:

The CRA’s “without delay” vulnerability handling requires tools that find issues fast and enable rapid fixing. StackHawk’s CI/CD-native approach creates the continuous testing and rapid remediation capabilities the CRA mandates. It maintains the development velocity modern software requires. Security shifts from “audit after the fact” to “validate continuously.”

4. Modern Architecture Support: Testing What CRA Actually Covers

CRA Requirement: The regulation covers all “products with digital elements” with network or device connectivity. This includes APIs, microservices, cloud-native applications, IoT, and embedded software. You must test across the complete technology stack organizations actually use.

The challenge: Legacy DAST tools were built for monolithic web applications. Modern software uses distributed architectures, multiple protocols, and AI-powered components. Compliance tools must test what you actually build.

How StackHawk supports modern architectures:

StackHawk provides comprehensive protocol and architecture support:

• API protocols: REST, GraphQL, gRPC, SOAP—complete coverage
• Microservices: Service-to-service communication and authentication testing
• Modern web: SPAs and JavaScript-heavy applications with dynamic content
• Complex authentication: OAuth, JWT, SAML, API keys, multi-tenant flows
• Cloud-native: Kubernetes, containers, serverless functions

StackHawk was built specifically for modern architectures, not legacy DAST adapted for CI/CD.

How StackHawk finds CRA-relevant vulnerabilities:

StackHawk tests business logic vulnerabilities, not just injection flaws. CRA-relevant vulnerabilities include broken authorization, flawed business logic, and authentication bypasses. It goes beyond simple injection attacks to complex security scenarios and finds vulnerabilities that actually lead to security incidents. This tests what legacy DAST misses in modern applications.

StackHawk includes AI/LLM component detection and testing. It discovers and tests AI capabilities as teams integrate LLMs, tests AI-generated code and AI-powered features, and ensures AI-accelerated development doesn’t introduce undetected attack surface. This maintains security visibility as development velocity increases.

The compliance benefit:

The CRA covers the full spectrum of modern software products. StackHawk tests architectures organizations actually build: APIs, microservices, cloud-native apps. It ensures compliance across your real technology stack, not just legacy applications old DAST was designed for, but modern architectures the CRA actually regulates.

5. Technical Documentation and Compliance Evidence Generation

CRA Requirement: Technical documentation must demonstrate security throughout the development lifecycle. Evidence must prove conformity with Essential Cybersecurity Requirements (Annex I Parts I and II). Documentation must support CE marking and conformity assessment. Organizations must demonstrate “regular tests and reviews” of product security.

The challenge: CRA compliance is fundamentally a documentation challenge. You must prove you’ve built security in and tested throughout the lifecycle. Manual documentation creates burden and gaps.

How StackHawk automates evidence collection:

Every test automatically documents:

• What applications/APIs were tested and when
• Which security tests were executed
• What vulnerabilities were found (or confirmed absent)
• How findings were classified and prioritized
• When and how vulnerabilities were remediated and verified

This eliminates manual documentation burden while creating detailed technical records.

How StackHawk provides complete testing timeline:

Scan history shows which applications were tested, testing frequency, findings over time, and coverage evolution. This proves continuous security validation throughout development (satisfying the “regular tests and reviews” requirement). It demonstrates not just point-in-time checking but ongoing commitment, creating a comprehensive audit trail for conformity assessment.

How StackHawk supports vulnerability reporting:

Comprehensive details for each vulnerability include type, affected endpoints, exploit conditions, severity, and impact. This information supports the CRA’s strict vulnerability reporting timelines (24-hour initial, 72-hour detailed, 14-day final). Testing generates necessary documentation before incidents occur. You know your inventory and vulnerabilities before exploitation begins.

How StackHawk integrates with compliance management:

Findings and reports feed into GRC platforms and compliance management systems. This centralizes CRA evidence alongside other regulatory documentation. Security testing evidence becomes part of overall compliance posture. Integration with Jira, Slack, and other tools enables coordinated response.

How StackHawk supports conformity assessment paths:

StackHawk works for self-assessment (most products) or third-party notified body evaluation (Important/Critical products). Detailed findings, remediation records, and continuous testing history demonstrate both Part I (“secure by design”) and Part II (“regular tests”) requirements. This provides evidence for CE marking conformity.

The compliance benefit:

StackHawk’s automated evidence generation creates the technical documentation the CRA requires without manual burden. Comprehensive audit trails demonstrate continuous testing and vulnerability management. Every scan generates the proof of testing regulators demand.

Getting Started with StackHawk for CRA Compliance

The EU Cyber Resilience Act changes software security from optional to legally required. By December 11, 2027, products must prove security was designed from the start, tested throughout development, and maintained across the support period. Non-compliant products cannot be sold in the EU market. Fines reach €15 million or 2.5% of global annual turnover.

StackHawk’s shift-left approach aligns with CRA requirements:

• Secure by design: Runtime testing validates security before market release
• Complete coverage: Automatic API discovery ensures no shadow APIs escape testing
• Continuous validation: CI/CD-native testing throughout product support period
• Documented evidence: Audit trails and exportable scan history for compliance verification

The challenge is achieving compliance without crippling development speed. StackHawk enables both: comprehensive CRA-aligned testing that runs in minutes, integrates into developer workflows, and catches vulnerabilities while still fixable without production impact. Ready to align your testing with CRA requirements? Schedule a demo to see how StackHawk supports pre-production testing and CRA compliance evidence generation.