Showing posts with label NIS2. Show all posts
Showing posts with label NIS2. Show all posts

Wednesday, July 15, 2026

The EU Cyber Resilience Act Deadline Is 2 Months Away: What Your Dev Team Must Ship Before September 11, 2026


If your product touches the EU market, the clock on the Cyber Resilience Act (CRA) just got a lot louder. September 11, 2026 is not the CRA's headline deadline that distinction belongs to December 11, 2027, when full conformity requirements apply. But the obligation landing in two months is arguably the one engineering teams are least prepared for: mandatory vulnerability and incident reporting under Article 14.

Most teams have spent the last year planning around 2027. That's the wrong horizon. September 2026 is a current-portfolio problem, not a future-product one, and it applies to software and hardware already sitting in EU customers' hands.

What Actually Changes on September 11, 2026

The CRA (Regulation (EU) 2024/2847) entered into force on December 10, 2024. From September 11, 2026, manufacturers of "products with digital elements" must report to ENISA and their national CSIRT whenever they become aware of:

  • An actively exploited vulnerability in their product
  • A severe incident affecting the security of the product

The timeline is unforgiving and staged:

  1. Early warning within 24 hours of becoming aware — a bare-bones notification, not a full report
  2. Full notification within 72 hours — more detail on nature, severity, and indicators of compromise
  3. Final report within 14 days after a corrective measure is available (for exploited vulnerabilities), or within one month for severe incidents

Reporting goes through the CRA Single Reporting Platform, and manufacturers report only once, with the notification routed to the relevant authorities. Note that vulnerability patching and remediation obligations don't formally kick in until December 11, 2027 but you can't report what you haven't detected, and you can't detect what you haven't inventoried. That's why the real work starts now.

Why Dev Teams, Not Just Legal, Own This

Compliance teams can write policy, but Article 14 is fundamentally an engineering problem. Reporting "actively exploited vulnerabilities" within 24 hours requires:

  • Real-time visibility into every open-source and third-party component in production
  • A working Software Bill of Materials (SBOM) generation pipeline
  • Automated vulnerability monitoring tied to exploit intelligence feeds, not just CVE publication
  • An internal escalation path that can move from "we detected this" to "regulator notified" in under a day

None of that exists overnight. If your team is only starting SBOM generation now, you're behind — most compliance practitioners recommend having automated SBOM and vulnerability-tracking pipelines operational well before the reporting clock starts, since accurate component-level visibility is the prerequisite for the 24-hour trigger, not a nice-to-have.

The Pre-September Checklist

Here's what needs to ship before the deadline, roughly in priority order:

1. Map your CRA scope. Inventory every product your organization manufactures, imports, or distributes that qualifies as a "product with digital element" under the CRA, and determine your role manufacturer, OEM, distributor, or importer since obligations differ by role.

2. Stand up SBOM automation. Every build pipeline should generate an SBOM automatically, in a machine-readable format, covering at minimum top-level dependencies. Manual, quarterly SBOM exports will not support a 24-hour reporting SLA.

3. Wire vulnerability monitoring to exploit intelligence. Article 14 triggers on actively exploited vulnerabilities, not every new CVE. Your tooling needs to distinguish the two, or your security team will drown in false alarms while missing the ones that actually require reporting.

4. Build the reporting workflow now, not in August. Register for the ENISA Single Reporting Platform, define who internally owns the 24-hour early warning, and rehearse the process with a tabletop exercise. This overlaps closely with incident-reporting muscle many EU-facing teams have already built for NIS2 organizations that have mapped out their NIS2 incident reporting timeline and 24/72-hour escalation paths have a head start, since CRA's staged reporting windows mirror that structure closely.

5. Test what you ship. Before September, run vulnerability assessments and penetration tests against production systems and flagship products to surface exploitable issues before an attacker or a regulator finds them for you. Structured, CREST-aligned penetration testing services give you a documented baseline of exploitable vulnerabilities and remediation priorities that directly feeds your CRA vulnerability-handling process.

6. Align CRA and NIS2 obligations. Many organizations in scope for the CRA are also "essential" or "important" entities under NIS2, which carries its own incident reporting and risk-management requirements. Rather than running two disconnected compliance tracks, unify governance, detection, and reporting workflows across both. Firms that already work with a NIS2 compliance consultancy and audit partner are finding it far easier to extend that same evidence base to CRA reporting, since the underlying detection and escalation infrastructure overlaps heavily. For teams also navigating financial-sector rules, this guide on NIS2 vs DORA is a useful companion for mapping overlapping obligations.

Don't Wait for December 2027 to Start Caring

It's tempting to treat the CRA as a 2027 problem because that's when full conformity assessment, CE marking, and secure-by-design documentation become mandatory. But Article 14 reaches products already on the market there's no grace period for legacy code. A single missed or late report after September 11, 2026 can trigger regulatory scrutiny, and for many organizations the operational cost of getting caught unprepared will exceed the cost of building proper readiness now.

Two months is enough time to stand up an SBOM pipeline, wire up exploit-aware vulnerability monitoring, and rehearse your reporting workflow but only if your dev team starts this sprint, not next quarter.

If you need an outside view on where your organization actually stands, a structured gap assessment across CRA, NIS2, and related EU frameworks is the fastest way to find out. VISTA InfoSec's compliance and security advisory team works with engineering and compliance leaders across the US, UK, EU, and Asia to close exactly these kinds of gaps before regulatory deadlines land.

Wednesday, June 17, 2026

DORA's First Threat-Led Penetration Tests Are Here: What Financial Entities Must Prove in 2026



For the first time since the Digital Operational Resilience Act (DORA) came into force, European financial entities are receiving official notifications to undergo Threat-Led Penetration Testing (TLPT). This is not a routine compliance exercise. It is a live, regulator-mandated simulation of a real cyberattack against your organisation's most critical systems, and the results will determine how supervisors view your operational resilience for years to come.


If your organisation is a bank, insurer, asset manager, payment provider, or an ICT service provider supporting any of these, 2026 is the year DORA stops being a compliance document and starts being an operational reality. Here is exactly what is happening, what is required of you, and how to prepare.


From Guidance to Enforcement: Where DORA Stands in 2026

DORA has been fully enforceable since January 17, 2025, following a two-year transition period. Unlike NIS2, which required each EU member state to transpose it into national law, DORA is a regulation, meaning it applies directly and uniformly across all member states without national variation. This is the regulatory backbone for ICT risk management across the EU financial sector.


What makes 2026 distinct is that European Supervisory Authorities, the EBA, EIOPA, and ESMA, have now finalised the detailed Regulatory and Implementing Technical Standards that specify exactly how compliance must be demonstrated. Supervisors are no longer issuing guidance. They are conducting audits, scrutinising ICT third-party contracts, and issuing the first formal TLPT notifications to in-scope entities.


What Is Threat-Led Penetration Testing (TLPT) Under DORA?

TLPT is DORA's most advanced testing requirement. It mandates that designated financial entities undergo a controlled, intelligence-led simulated cyberattack against their live production systems, replicating the tactics of real threat actors rather than running a standard vulnerability scan.


Entities that receive a TLPT notification have a defined timeline to respond: three months to submit initiation documents, followed by six additional months to deliver a detailed scope specification before testing begins. This is a significant undertaking that touches threat intelligence, red-team execution, and senior management sign-off, not something that can be arranged in the final weeks before a deadline.


The first wave of TLPT notifications is being issued in late 2026, with subsequent waves continuing into 2027. Entities should not assume they are out of scope simply because they have not yet been notified. Designation criteria consider systemic importance, and the list of in-scope entities is expected to expand.


The Register of Information: Your Most Urgent 2026 Deadline

While TLPT is the headline-grabbing requirement, the Register of Information (RoI) under Article 28 of DORA is the obligation affecting every single financial entity in scope, right now. The RoI is a comprehensive register documenting all contractual arrangements with ICT third-party service providers, covering everything from your cloud infrastructure provider to your data analytics vendor.


National competent authorities must consolidate and forward these registers to the European Supervisory Authorities by March 31, 2026, using a reference date of December 31, 2025. Individual countries have set their own internal submission windows ahead of this backstop date. For example, German entities submit to BaFin between March 9 and 30, Dutch entities submit to DNB or AFM by March 20, and Irish entities submit to the Central Bank of Ireland between March 2 and 31.


This is widely regarded as the most data-intensive obligation under DORA. During the European Supervisory Authorities' 2024 dry-run exercise, only a small fraction of nearly 1,000 participating firms successfully passed all data quality checks on their first attempt, underscoring just how easy it is to get this wrong. Submissions must follow a strict xBRL-CSV format, and errors trigger a resubmission cycle that can quickly eat into your remaining time.


Why ICT Third-Party Providers Should Pay Close Attention Too

DORA's reach extends well beyond banks and insurers. If your organisation provides software, cloud hosting, cybersecurity services, or any technology service to a financial entity operating in the EU, you are part of the ecosystem DORA regulates, even if you are not directly supervised.


The European Supervisory Authorities have already published an official list of Critical ICT Third-Party Providers, including major hyperscale cloud providers and global technology and telecom firms. These designated providers face direct oversight from Joint Examination Teams. Financial entities relying on any of these providers must document the dependency in their Register of Information and assess concentration risk accordingly. In practice, this means your financial sector clients will increasingly demand proof of your own security posture, incident response capability, and resilience testing before renewing contracts.


DORA vs NIS2: Understanding the Overlap

Many organisations operating in regulated sectors are now navigating both DORA and NIS2 simultaneously, and the relationship between the two matters. DORA acts as lex specialis to NIS2 for the financial sector, meaning that where the two frameworks overlap, DORA's more specific and stringent requirements take precedence for in-scope financial entities.


If your organisation has already built NIS2 compliance processes around incident reporting, risk management, and supply chain oversight, you have a meaningful head start. However, DORA introduces requirements that go further, particularly around the Register of Information and Threat-Led Penetration Testing, which have no direct equivalent under NIS2. Equally, a strong ISO 27001 information security management system provides a solid foundation, since a large proportion of ISO 27001 controls map directly onto DORA's ICT risk management pillar.


Your DORA 2026 Compliance Checklist

  • Confirm your in-scope status: Determine whether your organisation, or your role as an ICT provider to financial entities, falls within DORA's regulatory perimeter.
  • Build and validate your Register of Information: Document every ICT third-party contractual arrangement at entity, sub-consolidated, and consolidated level, formatted correctly for xBRL-CSV submission.
  • Map your national submission window: Confirm your country's specific RoI deadline ahead of the March 31, 2026 ESA backstop date.
  • Run internal data quality checks: Validate LEI and entity identifiers, check for duplicate records, and confirm consistency across all contracts before submission.
  • Prepare for TLPT readiness: Even without a notification yet, establish threat intelligence capability, red-team processes, and senior management sign-off procedures.
  • Review your ICT risk management framework: Ensure it is documented, board-approved, and reviewed on an ongoing basis as DORA requires.
  • Strengthen incident reporting workflows: DORA requires major incidents to be reported within hours, not days, so test your detection and escalation timelines.
  • Reassess critical ICT third-party dependencies: Identify any reliance on designated Critical ICT Third-Party Providers and document concentration risk.
  • Align with existing ISO 27001 or NIS2 programmes: Avoid duplicating effort by mapping shared controls across frameworks.

How Vista Infosec Can Help

DORA compliance is technically demanding and time-sensitive, but it does not have to be navigated alone. Vista Infosec is a CREST-accredited global cybersecurity and compliance consulting firm with over 20 years of experience helping financial entities and ICT providers across the US, UK, Singapore, India, and the Middle East meet rigorous regulatory standards.


Our team can help you:

  • Conduct a DORA gap assessment and build or validate your Register of Information ahead of national deadlines.
  • Design and execute penetration testing aligned withTLPT methodology and audit expectations.
  • Strengthen your ICT risk management framework and incident reporting processes.
  • Map DORA requirements against your existing ISO 27001, SOC 2, or NIS2 controls to streamline compliance and reduce audit fatigue.

 

Do not wait for a TLPT notification to discover gaps in your resilience. Get assessed now and walk into your next regulatory audit with confidence.

 

Book a free 30-minuteconsultation with Vista Infosec today.

Monday, June 08, 2026

Agentic AI and Cybersecurity in 2026: Why Your Business Is More Vulnerable Than You Think


We are barely halfway through 2026, and the cybersecurity landscape has already been turned on its head. Ransomware? Still a threat. Phishing? Evolving fast. But there is a new challenger at the top of the threat rankings one that most businesses are not even remotely prepared for.


Agentic AI.


According to a 2026 Dark Reading poll, 48% of cybersecurity professionals now rank agentic AI as the top attack vector of the year outranking deepfakes, ransomware variants, and supply chain breaches. This is not a future concern. It is happening right now, inside your organisation, possibly without your knowledge.


So what exactly is agentic AI, why is it so dangerous, and more importantly what can your business do about it? Let us break it all down.


What Is Agentic AI, and Why Should You Care?

Traditional AI tools think chatbots, recommendation engines, or auto-fill assistants respond to prompts. They wait for instructions and produce outputs. Agentic AI is fundamentally different.


Agentic AI systems are autonomous. They can pursue goals through multi-step workflows, coordinate with other tools, take actions, and adapt plans as new information arrives. They do not just answer questions they do things. They can open pull requests in your code repository, query internal databases, trigger cloud workflows, book services, and interact with other AI agents all with minimal human involvement.


In business environments, this sounds like incredible productivity. And it is. But it also introduces a category of security risk that legacy cybersecurity frameworks were simply never designed to handle.


The Hidden Threat: Shadow AI and Non-Human Identities

Here is where things get particularly alarming for IT and security teams.


Employees across organisations are importing unsanctioned AI tools into work environments often without any security oversight. This is called Shadow AI, and it is one of the fastest-growing blind spots in enterprise security today. Research shows that more than one-third of all data breaches now involve unmanaged shadow data much of it generated or accessed by AI agents operating outside monitored channels.


Compounding this is the rise of non-human identities (NHIs). Every AI agent deployed within an organisation requires API access, machine-to-machine authentication, and elevated permissions. The Huntress 2026 data breach report identified NHI compromise as the fastest-growing attack vector in enterprise infrastructure this year. Developers often hardcode API keys in configuration files or leave them in version control repositories. A single compromised agent credential can provide attackers access equivalent to that agent's permissions for weeks or months, completely undetected.


Now multiply that across a complex multi-agent system, where one orchestration agent holds credentials for five downstream agents. If that orchestration layer is compromised, an attacker gains access to every one of those downstream systems simultaneously.


This is not hypothetical. In 2026, a supply chain attack on the OpenAI plugin ecosystem resulted in compromised agent credentials being harvested from 47 enterprise deployments.


Specific Risks Your Security Team Needs to Know

Agentic AI introduces several distinct attack surfaces that require targeted security strategies:


1. Prompt Injection and Manipulation

Attackers can embed malicious instructions into data that an AI agent processes — effectively hijacking the agent's actions without ever touching the underlying system directly.


2. Tool Misuse and Privilege Escalation

AI agents operating with elevated permissions can be manipulated into accessing resources beyond their intended scope, creating a pathway for lateral movement within your network.


3. Memory Poisoning

Long-running agents that retain context across sessions can be fed false information, corrupting their decision-making logic over time in ways that are difficult to detect.


4. Cascading Failures in Multi-Agent Systems

In interconnected agent architectures, a compromise or misconfiguration in one agent can cascade rapidly across the entire system amplifying both the speed and scale of an incident.


5. Agent-to-Agent Impersonation

Attackers can exploit the implicit trust between agents in a pipeline, using impersonation, session smuggling, and unauthorised capability escalation to move laterally across systems.


What Does This Mean for Compliance?

If your organisation operates under ISO 27001, SOC 2, GDPR, HIPAA, NIS2, or DORA, the arrival of agentic AI creates immediate compliance implications that cannot be ignored.


Governance frameworks built even two or three years ago simply did not anticipate AI agents as participants in business processes. Today, these agents are accessing sensitive data, triggering transactions, and generating audit trails or failing to generate them, which may itself constitute a compliance breach.


Gartner has flagged global regulatory volatility as one of the top cybersecurity trends of 2026, advising security leaders to formalise collaboration across legal, business, and procurement teams to establish clear accountability for AI-driven risk. Rapid incident reporting requirements sometimes within 24 hours are already live under frameworks like DORA and NIS2. Manual, human-only processes are unlikely to keep pace.


The good news? Agentic compliance systems are emerging that can monitor regulatory changes, identify impacted policies, update internal workflows, and create a complete audit chain bringing compliance closer to continuous control management. But deploying these systems safely requires expertise.


How Should Businesses Respond? A Practical Framework

Whether you are a startup, an SME, or an enterprise, the following steps are non-negotiable in 2026:


Step 1: Conduct an AI Asset Inventory
Step 2: Audit Non-Human Identities
Step 3: Include AI Systems in Your Penetration Testing Scope
Step 4: Update Your Incident Response Playbook
Step 5: Align with a Recognised Security Framework
Step 6: Train Every Employee, Not Just the Security Team


You cannot secure what you cannot see. Begin by mapping every AI tool sanctioned or otherwise in use across your organisation. Include third-party integrations, developer-side tools, and any system with API access to internal data.


Review every machine identity, service account, and API key in your environment. Implement the principle of least privilege rigorously no agent should have more access than it absolutely needs to perform its defined function.


Traditional penetration testing focuses on applications, networks, and infrastructure. In 2026, your penetration testing engagement must explicitly include AI agents, their integration points, and their associated credentials as part of the test scope. If your current vendor is not doing this, it is time to ask why.


Your incident response plans need to account for AI-driven incidents including scenarios where an agent has been operating maliciously for days or weeks before detection. Define clear escalation paths, containment procedures, and communication protocols specific to AI-related breaches.


Adopt or review your alignment with OWASP's Top 10 for LLM Applications and the MITRE ATLAS framework, both of which address AI-specific threats. These sit alongside your existing ISO 27001 or SOC 2 programme and provide targeted guidance for agentic system security.


AI governance is an enterprise-wide responsibility. Every employee from entry-level staff to board members needs to understand what data can and cannot be used in AI tools, and how to recognise social engineering attacks that are now enhanced by AI-generated content.


The Bigger Picture: Cybersecurity Is No Longer Just an IT Problem

Gartner's analysis of 2026 trends makes one thing crystal clear: cybersecurity has become a board-level business risk, with regulators increasingly holding executives and directors personally liable for compliance failures. Inaction is no longer defensible it carries substantial penalties, operational restrictions, and irreversible reputational damage.


The organisations that will thrive in this environment are not necessarily those with the largest security budgets. They are the ones with the clearest governance structures, the most rigorous testing protocols, and the right advisory partnerships to help them navigate an increasingly complex threat and compliance landscape.


Secure Your AI-Driven Future With Expert Guidance

The cybersecurity challenges of 2026 are real, evolving, and consequential. But they are also manageable with the right expertise on your side.


At Vista Infosec, we help organisations across Singapore, the United States, the United Kingdom, and India navigate the intersection of emerging threats and compliance requirements. From VAPT (Vulnerability Assessment and Penetration Testing) that now covers AI systems, to GDPR, NIS2, and ISO 27001 compliance consulting our team of CREST-accredited security professionals brings the depth of experience your organisation needs to stay secure and audit-ready in 2026 and beyond.


Do not wait for an incident to find the gaps. Get a security assessment today.


Contact Vista Infosec

EU AI Act's GPAI Rules Are Now Enforceable: What Changed on August 2, 2026 (And What Your Team Missed)

For twelve months, Brussels asked nicely. As of August 2, 2026 , it doesn't have to anymore. If your compliance team spent the summer c...