Introduction
National cybersecurity cannot be reduced to a CERT.
It cannot be reduced to a SOC.
It cannot be reduced to NIS2 compliance, penetration testing, audits or one national security platform.
Digital resilience emerges from overlapping layers.
Some are preventive:
- Secure by Design;
- secure configuration;
- supply-chain control;
- identity and access management.
Some produce planned assurance:
- vulnerability assessment;
- penetration testing;
- red teaming;
- audit;
- sectoral testing.
Some operate continuously in production:
- telemetry;
- detection;
- threat intelligence;
- incident response;
- recovery.
There is another layer that is easy to under-design:
an independent outsider notices a vulnerability that internal controls did not identify and has a trusted route to turn that observation into remediation.
That is security research as a layer of national cyber resilience.
Not a replacement for government security functions.
Not an army of unpaid penetration testers.
Not a privilege to test arbitrary systems.
It is a decentralised discovery signal that a national cybersecurity architecture is able to receive, validate, coordinate and convert into security improvement.
National resilience is already a multi-stakeholder problem
Latvia is a useful concrete case.
Its current Cybersecurity Strategy 2023–2026 defines five policy directions:
- improving cybersecurity governance;
- promoting cybersecurity and strengthening resilience;
- public awareness, education and research;
- international cooperation and rule of law in cyberspace;
- prevention and combating of cybercrime.1
The Ministry of Defence also describes national cybersecurity governance as a cooperative system involving public institutions, the private sector and national coordination mechanisms.2
That is the right starting point.
Resilience is not the capability of one agency.
It is the ability of the system to:
Independent researchers can contribute primarily to detection and understanding.
The remaining chain is still an institutional responsibility.
detect
→ understand
→ coordinate
→ act
→ recover
→ learn NIS2 turns external discovery into a national function
Article 12 of NIS2 requires each Member State to designate a CSIRT as coordinator for coordinated vulnerability disclosure.4
Where necessary, that coordinator acts as a trusted intermediary between the natural or legal person reporting a vulnerability and the manufacturer or provider responsible for the potentially vulnerable ICT product or service.
That changes the nature of an external vulnerability signal.
It no longer has to remain:
somebody emailed a company.
In a mature national architecture, it can become:
NIS2 also explicitly provides for coordination where one vulnerability affects multiple entities or has significant cross-border impact.4
CVD is therefore more than a customer-support workflow.
It is part of national vulnerability governance.
external discovery
→ national CVD route
→ technical validation
→ affected owner
→ remediation
→ multi-party / cross-border coordination where needed Latvia already has the institutional foundations
Latvia's National Cybersecurity Centre acts as the single point of contact for cybersecurity matters, with its functions implemented by the Ministry of Defence together with CERT.LV.2
The Ministry's published description of the Centre's tasks includes participation in coordinated vulnerability disclosure, cross-border incident coordination, maintenance of a national cyber situational picture and public threat information.3
CERT.LV operates cvd.cert.lv as the national vulnerability-reporting and coordination platform.5
The platform:
- records vulnerability reports;
- preserves communication between relevant parties;
- allows resource owners to define testing programmes and rules;
- gives researchers a route to submit vulnerabilities even where a dedicated programme cannot be found, through a general CERT.LV-client route.5
Those are already the basic components of a national external-discovery layer.
2026 shows movement from abstract CVD toward sector participation
By September 2026, CERT.LV's platform contains programmes for socially important organisations including:
The programmes are not identical.
The State Revenue Service, for example, restricts active testing to defined hours and prohibits activity that could affect normal service operation.8
Sadales tīkls requires researchers to be registered on the platform and defines a controlled programme for its web-facing scope.11
This demonstrates an important national-resilience principle:
one national coordination mechanism can support different testing-risk profiles without imposing one universal research model on every organisation.
That is what layered resilience should look like.
External researchers fill a temporal and cognitive gap in planned testing
Penetration testing is normally:
- scheduled;
- scoped;
- time-boxed;
- performed by a defined team.
Independent research can occur:
- between assessments;
- after a new release;
- against an asset nobody prioritised;
- through a technology combination not covered by the original test;
- by a researcher with a very different technical background.
Its value is not simply:
more people testing means more security.
Its value is independent observation error.
Internal teams, scanners and contracted testers may share assumptions.
An outsider may start from a different hypothesis altogether.
That diversity reduces the chance that an entire assurance system repeatedly misses the same class of weakness.
But CVD is not a national penetration test
CERT.LV makes this boundary explicit: vulnerability research and reporting through the platform are not equivalent to a comprehensive security assessment, penetration test or vulnerability-testing service.6
That distinction is essential.
The existence of CVD does not support the claim:
It supports a different claim:
A resilient national model needs both:
- planned, funded and systematic assurance;
- unplanned external discovery.
public systems have been comprehensively tested external findings have a route into the system A national resilience stack
I would model national digital resilience through at least seven overlapping layers.
1. Secure design and build
Organisations prevent predictable defect classes before deployment.
2. Asset and vulnerability visibility
The organisation knows what exists, which versions are running and what known vulnerabilities affect them.
CERT.LV's 2026 resilience recommendations explicitly emphasise maintaining an ICT resource inventory and monitoring public vulnerability information.7
3. Planned assurance
Penetration tests, red teams, audits, sector-specific assessments and other authorised exercises.
4. External discovery
CVD, VDPs, bug bounty and other good-faith independent security research.
5. Threat and exploit intelligence
Known vulnerability information, exploitation signals, campaign intelligence and real threat activity.
6. Incident response and crisis coordination
When a vulnerability moves from potential exposure to evidence of compromise, the process transitions to incident response.
7. Recovery and learning
Root cause, regression tests, policy, supplier controls and system design are changed so that one finding can improve the wider system.
The external researcher primarily occupies layer four.
A good report can activate nearly every other layer.
A signal is not a decision
At national scale, this distinction becomes critical.
A researcher can state:
I can reproduce unauthorised cross-account access.
That is technical evidence.
The researcher does not unilaterally determine:
- national risk;
- supervisory priority;
- incident status;
- classification;
- service shutdown;
- disclosure timing;
- risk acceptance.
The correct chain is:
not:
The researcher's value comes partly from independence.
The institutional decision derives from context and accountability.
researcher evidence
→ validation
→ operational context
→ responsible owner
→ risk / incident decision researcher labels it Critical
→ the state treats it as Critical The researcher is an external sensor, not a command centre
A national architecture can use independent researchers as:
- early-warning sources;
- blind-spot detectors;
- external testers of security assumptions;
- discoverers of novel technical patterns.
That does not give the researcher:
- incident-command authority;
- permission to modify systems;
- supervisory powers;
- unrestricted publication rights.
Clean role boundaries are precisely what make external research safe enough to integrate into national resilience.
Multi-party vulnerabilities are where national coordination becomes most valuable
The simple case is:
The difficult case involves:
- a shared open-source component;
- a cloud platform;
- a government shared service;
- an identity provider;
- a telecommunications dependency;
- a product used across many public bodies.
One recipient cannot resolve the issue alone.
The flow may need to become:
This trusted-intermediary and multi-party coordination function is exactly the kind of role NIS2 assigns to national CVD coordinators.4
At that point, CVD is visibly resilience infrastructure.
researcher → website owner researcher
→ coordinator
→ upstream vendor
→ affected public/private entities
→ sector authorities
→ cross-border CSIRTs where needed A single finding can become vulnerability intelligence
Not every finding should become a public national advisory.
But a validated external report can trigger broader questions:
- Is the same product deployed elsewhere?
- Is the weakness upstream?
- Is it one configuration or a whole defect class?
- Is exploitation known?
- Should the sector perform targeted checks?
- Is national guidance needed?
- Should variants be searched elsewhere?
The lifecycle then expands:
That is more valuable than merely closing one ticket.
single finding
→ validated root cause
→ affected-product mapping
→ sector / national exposure question
→ targeted search / mitigation Researcher findings can also test national methodology
If unrelated organisations repeatedly receive the same class of external finding, the problem may not be “five bad developers”.
It may indicate:
- a common framework pattern;
- a weak reference architecture;
- procurement requirements missing a control;
- insufficient logging guidance;
- a shared supplier;
- a recurring IAM design failure;
- a gap in secure-development methodology.
CVD data can therefore be useful not only to the resource owner but also to:
- methodology owners;
- procurement-policy designers;
- sector supervisors;
- shared-platform owners.
This is a resilience learning loop.
Central learning requires careful data governance
A national CVD system should not become a public catalogue of unresolved sensitive weaknesses.
Analytics needs to distinguish:
- sensitive case evidence;
- aggregated programme metrics;
- anonymised defect taxonomy;
- publishable advisory information;
- incident-sensitive or otherwise restricted information.
A useful principle is:
learn centrally without exposing unnecessarily.
For example, a national coordinator may observe recurring broken-access-control patterns without publicly identifying vulnerable institutions or exploit details before remediation.
CVD must connect to incident response
Suppose an external report is validated and investigators discover:
- evidence of prior exploitation;
- suspicious logs;
- data-exfiltration indicators;
- persistence;
- compromised credentials.
The case can no longer remain only a vulnerability-remediation workflow.
A resilient architecture needs a predesigned transition:
CVD can be a detection route.
It should not become a parking lot for an incident.
external finding
→ vulnerability validation
→ evidence of compromise?
├─ no → remediation / disclosure
└─ yes → incident response + remediation National coordination should not mean centralising research itself
One tempting model is:
one government-approved researcher registry, one national reputation score, one central testing programme.
That can create new failure modes:
- barriers to new talent;
- institutional bias;
- reputation lock-in;
- homogeneous research habits;
- slow onboarding of new scope;
- excessive control over independent security work.
Part of resilience comes from decentralised observation.
I would therefore use a simpler principle:
decentralised discovery, coordinated handling.
Researchers do not need to belong to one organisation.
Findings do need a trusted path.
Critical systems need differentiated testing, not exclusion from external research
Not every national asset can tolerate the same research model.
A public information site, tax service, election system, power-grid control component and clinical device do not have the same testing-risk profile.
So:
Some scope can use:
- public low-impact CVD;
- registered researchers;
- invitation-only research;
- controlled professional testing.
I explore this separately in Security Research in Critical Systems.
The national objective should not be maximum testing freedom.
It should be maximum safe, independent evidence.
open reporting
≠ universal open testing The researcher ecosystem is latent capacity, not automatic capacity
A state can deploy a technically good CVD platform.
That does not guarantee that strong researchers will use it repeatedly.
Participation also depends on:
- legal clarity;
- technically competent triage;
- feedback;
- recognition;
- progression;
- and, in some programmes, monetary reward or funded research.
For that problem, see Permission Is Not Participation.
From a national-resilience perspective, the implication is straightforward:
a researcher population becomes capacity only when the system can activate and retain it.
What not to measure
A weak national KPI would be:
We received 40% more vulnerability reports this year.
That could mean:
- more researchers;
- more vulnerabilities;
- more noise;
- broader scope;
- repeated discovery of old issues;
- a better reporting channel.
Without context, it says very little.
Another weak KPI:
We now have 100 programmes.
If those programmes have:
- no meaningful scope;
- no researchers;
- weak triage;
- slow remediation;
- no closure;
programme count is an administrative output.
Not a resilience outcome.
What I would measure at national CVD/resilience level
Coverage
- how many socially important sectors have a usable CVD path;
- how many relevant resources have a discoverable reporting route;
- how many offer defined active-research scope;
- where “nobody knows where to report” still exists.
Signal quality
- validated finding ratio;
- unique root causes;
- multi-party findings;
- findings with broader sector impact;
- CVD-to-incident-response escalations.
Response
- acknowledgement time;
- technical-validation time;
- owner assignment;
- remediation initiation;
- retest and verified-closure coverage.
Learning
- recurring root causes;
- findings that trigger methodology or control changes;
- findings exposing shared suppliers or common components;
- national or sector guidance derived from real evidence.
Ecosystem health
- active useful researchers;
- returning researchers;
- participation distribution across programmes;
- out-of-scope and dispute signals;
- researcher feedback on process quality.
None of these is a single “national resilience score”.
Together they provide evidence about the system.
A National Research Signal Record
To learn across organisations without exposing sensitive case details, a minimal standardised metadata record could be useful.
For example:
Without:
- personal data;
- exploit secrets;
- sensitive addresses;
- unnecessary profiling of individual researchers.
This is my analytical model, not the current CERT.LV data schema.
The purpose is to make one case capable of contributing to aggregated resilience evidence.
signal:
source: external_research
received_at:
sector:
asset_class:
finding:
vulnerability_class:
root_cause_class:
demonstrated_impact:
exploitation_evidence: yes/no/unknown
multi_party: yes/no
coordination:
owner_assigned:
csirt_coordination:
cross_sector:
cross_border:
treatment:
mitigation:
remediation:
retest:
disclosure_status:
learning:
repeat_pattern:
shared_component:
methodology_change:
sector_guidance_needed: External research should sit inside one assurance map
A national architecture becomes weaker when every security-evidence source lives in its own conceptual world:
A mature model does not necessarily centralise all of that into one database.
It centralises the semantics:
- what is a finding;
- who owns it;
- what counts as remediation;
- when does it become an incident;
- what does closed mean;
- what is a repeat root cause;
- what qualifies as a cross-sector signal.
That common language matters more than another giant dashboard.
pentest reports somewhere
CVD somewhere else
incident data elsewhere
supplier advisories elsewhere
scanner findings in another system Why this is a resilience question rather than only a CVD question
The objective of one organisation's CVD programme is to remediate a specific vulnerability.
The national-resilience question is larger:
What does this finding tell us about the system around it?
Does it expose:
- a shared supplier;
- a recurring configuration pattern;
- a new attack technique;
- weak national guidance;
- a sector with poor assurance coverage;
- an institution unable to absorb external reports;
- a weakness worth searching for elsewhere?
At that point, external research moves from case handling to system learning.
Conclusion
An external security researcher is not, by themselves, a national cybersecurity capability.
The capability exists only when institutions can take the researcher's signal and:
receive → validate → contextualise → coordinate → remediate → retest → learn.
Latvia already has important foundations for that architecture:
- national cybersecurity governance;
- the National Cybersecurity Centre;
- CERT.LV;
- a statutory CVD process;
- an actively developed national vulnerability-reporting platform;
- programmes operated by public and socially important organisations.25
The next maturity question is therefore not simply:
How many programmes can we open?
It is:
Can we turn independent external security signals into a repeatable national resilience learning loop?
That is where security research becomes a layer of national cyber resilience.
Not because the researcher replaces the state.
Because a mature state knows how to use independent external evidence without outsourcing responsibility for what happens next.
Frequently asked questions
Can external researchers replace national penetration testing and audits?
No. CVD provides unplanned external discovery but does not guarantee systematic coverage. Planned, funded professional assurance remains necessary.
Does national resilience require one government registry of “ethical hackers”?
Not necessarily. Central registries may be useful for selected sensitive programmes, but resilience also benefits from decentralised independent discovery. A stronger default principle is “decentralised discovery, coordinated handling”.
Should every public-sector system be open to public testing?
No. Reporting should be clear, while active-testing authority should be proportionate to the system's potential consequence and legal boundaries.
Is the CERT.LV platform a national penetration test?
No. CERT.LV explicitly states that vulnerability research and reports submitted through the platform are not equivalent to a comprehensive security assessment or penetration test.6
How can one vulnerability report have national value?
After validation, the coordinator or responsible organisations can assess whether the same root cause, product or component exists elsewhere. One case can therefore become a sector or national vulnerability-intelligence signal.
Do more vulnerability reports mean more resilience?
Not necessarily. Raw volume without context on validity, coverage, remediation, retest, recurring root causes and researcher participation is a weak resilience measure.
Source status
Sources and Latvian institutional status checked on 25 September 2026. The seven-layer national-resilience stack, “decentralised discovery, coordinated handling” principle, proposed metrics and National Research Signal Record are the author's analytical models, not official methodologies of Latvia's Ministry of Defence, National Cybersecurity Centre, CERT.LV or ENISA.
This article analyses national cyber-resilience and CVD architecture. It is not an official interpretation of Latvian cybersecurity policy.
Sources
- Latvia, Ministry of Defence, Cybersecurity Strategy — Latvian Cybersecurity Strategy 2023–2026 and its five policy directions · mod.gov.lv
- Latvia, Ministry of Defence, Cybersecurity — national cybersecurity governance and the National Cybersecurity Centre · mod.gov.lv
- Latvia, Ministry of Defence, Nacionālā kiberdrošības centra uzdevumi un tiesības [Latvian] · mod.gov.lv
- Directive (EU) 2022/2555 (NIS2), particularly Article 12 and Recitals 58–62 on coordinated vulnerability disclosure · EUR-Lex
- CERT.LV, Vulnerability Reporting Platform Terms of Use, effective 1 August 2026 · CERT.LV
- CERT.LV, Vulnerability Reporting Platform FAQ, checked 25 September 2026 · CERT.LV
- CERT.LV, Recommendations for improving infrastructure cybersecurity resilience against cyber attacks, July 2026 [Latvian] · cert.lv
- CERT.LV CVD platform, State Revenue Service programme, checked 25 September 2026 · CERT.LV
- CERT.LV CVD platform, Central Election Commission programme, checked 25 September 2026 · CERT.LV
- CERT.LV CVD platform, LVRTC programme, checked 25 September 2026 · CERT.LV
- CERT.LV CVD platform, Sadales tīkls programme, checked 25 September 2026 · CERT.LV