Notifications
Clear all
Topic starter
02/08/2026 9:39 am
TL;DR: EU cybersecurity regulations such as DORA, CRA, and NIS2 are pushing AppSec teams toward secure-by-design development, continuous vulnerability management, software supply chain controls, and faster incident reporting, according to OXSecurity. The practical shift is that resilience and evidence of control are becoming as important as fixing vulnerabilities themselves.
NHIMG editorial — based on content published by OXSecurity: EU cybersecurity regulations and what they mean for AppSec teams
By the numbers:
- Breaches will incur fines of up to 2% of annual global turnover under DORA.
- CRA requires notification of actively exploited vulnerabilities to ENISA within 24 hours of discovery.
Questions worth separating out
Q: How should AppSec teams align controls across DORA, CRA, and NIS2?
A: Build one control map that links secure development, vulnerability management, supply chain assurance, testing, and incident reporting to each regulation.
Q: Why do software supply chains create identity governance risk?
A: Because the identities that sign, build, approve, and deploy software can change the final outcome more than the code itself.
Q: What breaks when vulnerability management is not continuous?
A: Periodic review leaves organisations unable to prove when a weakness was found, how quickly it was triaged, and whether the response met regulatory timelines.
Practitioner guidance
- Unify AppSec controls into a single compliance map Map secure development, vulnerability management, supply chain assurance, testing, and incident reporting to DORA, CRA, and NIS2 so teams can answer audit requests without rebuilding evidence for each regulation.
- Add NHI and secrets governance to supply chain reviews Include service accounts, API keys, tokens, and certificates in third-party and dependency assessments so application trust boundaries are evaluated as identity-driven control surfaces, not just code dependencies.
- Instrument response evidence for regulatory timelines Track when vulnerabilities were discovered, triaged, remediated, and reported so teams can prove whether they met expectations such as active exploit notification within 24 hours.
What's in the full article
OXSecurity's full article covers the operational detail this post intentionally leaves for the source:
- A regulation-by-regulation breakdown of DORA, CRA, and NIS2 obligations for application teams.
- Specific examples of secure development, testing, and reporting practices tied to each framework.
- The article's full discussion of supply chain security and vulnerability management expectations for AppSec.
- How the ASPM platform is positioned to support evidence collection and remediation workflows.
👉 Read OXSecurity's analysis of EU cybersecurity regulations and AppSec →
EU cybersecurity regulations for AppSec teams: what changes now?
Explore further
02/08/2026 12:34 pm
Compliance is becoming the language through which AppSec proves resilience. DORA, CRA, and NIS2 all reward the same operational behaviour: secure development, ongoing testing, dependency oversight, and timely response. That convergence means AppSec teams should stop treating regulatory obligations as a separate workstream and start using them as the evidence layer for resilience. The practical conclusion is that control design, audit readiness, and remediation discipline now need to be built together.
A question worth separating out:
Q: Who is accountable when application security compliance fails?
A: Accountability sits across AppSec, engineering, security leadership, compliance, and where credentials are involved, IAM or PAM owners. DORA, CRA, and NIS2 all imply that control ownership must be explicit and documented. If no one owns the evidence chain, the organisation will struggle to defend its resilience posture.
👉 Read our full editorial: EU cybersecurity rules are making AppSec a compliance discipline
