Fleuret raises €4M to build Europe's AI pentester.

API pentesting for NIS2 compliance: turning a test into audit evidence

Yanis Grigy, CEO10 min read

API pentesting for NIS2 compliance has to do more than find bugs. It has to show, with evidence, that your Article 21 cybersecurity risk-management measures work on real APIs, under real authentication, with fixes verified afterwards. The audit question is simple: can you prove the test was scoped to business-critical exposure, that the highest-risk issues were fixed, and that a retest confirms the control now works?

Key takeaways

  • A NIS2-relevant API pentest is evidence of control effectiveness, not compliance on its own.
  • Scope starts with the APIs that expose identity, partner access or operational data, not with the public documentation.
  • The findings that matter most are usually authorization and authentication failures, led by Broken Object Level Authorization.
  • Audit-ready output needs scope approval, findings, remediation owners, retest results and a traceable link to Article 21 measures.

A pentest supports NIS2 only if it proves control effectiveness

What NIS2 expects from testing

Article 21 of Directive (EU) 2022/2555 requires essential and important entities to take appropriate and proportionate technical, operational and organisational measures to manage cybersecurity risk, including policies to assess how effective those measures are. ENISA's technical implementation guidance, published in June 2025 alongside Implementing Regulation (EU) 2024/2690, is the current technical reference for turning that legal duty into controls you can test, repeat and defend in a review.

So the test is not the goal. The goal is proof that access control, secure development, logging, vulnerability handling and incident readiness are effective on the APIs that matter most. CodiTrust frames the difference well: a standard pentest lists vulnerabilities, while a NIS2 compliance pentest answers which Article 21 measures are technically insufficient and how to prove it.

What a pentest can and cannot prove

A one-off API pentest can prove that specific weaknesses existed, that they were exploitable, and that fixes were verified afterwards. It cannot prove that the whole program is compliant, because compliance also depends on continuous vulnerability management, governance and operational follow-through.

The claim that holds up in an audit is narrower and stronger: "We independently tested the internet-facing and partner APIs that handle identity and operational data, fixed the critical issues and verified the fixes by retest." That is evidence, and it is the right size of claim for a regulator. For the broader question of how often NIS2 expects you to test, see our piece on NIS2 pentest cadence for the mid-market.

Start with scope: map APIs to critical services and data

Which APIs belong in the first wave

Scope follows business impact. Start with customer-facing authentication APIs, partner integrations, admin APIs and any API tied to regulated data or to an operationally critical service. If an API can affect access, transactions or service availability, it belongs in the first wave.

How to avoid blind spots

  • Read the OpenAPI or Swagger files first. They expose endpoints, parameters and object shapes quickly, which gives you a real target list instead of a guessed one.
  • Include the hidden surface. Forgotten endpoints, shadow APIs, old versions and GraphQL schemas left exposed in production often matter more than the public portal. Invictis makes the point bluntly: paper NIS2 compliance is an illusion if shadow APIs stay invisible to your scanners.
  • Track owners and environments. If you cannot say who owns an API, where it runs and what data it touches, the scope is not audit-ready.
  • Prioritise exposure over size. A small partner API that handles credentials can deserve earlier testing than a large but low-risk internal service.

Test the API risks that matter most under NIS2

Authorization and identity flaws

The centre of gravity is the OWASP API Security Top 10, where Broken Object Level Authorization (BOLA) sits in first place, followed by broken authentication. Add broken object property level authorization (mass assignment) and injection, and you cover the classes that map directly to real compromise paths rather than theoretical weaknesses.

JWT testing should cover signature integrity, expiry and revocation, because token weaknesses turn into identity spoofing. GraphQL introspection left enabled in production is another high-value exposure: as Opsky's API pentest methodology notes, it can reveal the full schema and make the rest of the attack path much easier.

One example is enough to show why this matters. If changing an object ID in a request returns another customer's invoice, policy document or device record, object-level authorization is missing. That is a business failure first and a technical flaw second.

Input handling and business logic abuse

Input validation still matters, but for NIS2-relevant APIs the bigger concern is abuse that changes outcomes: mass assignment, parameter tampering, insecure deserialization, injection, and workflow manipulation such as skipping an approval step or replaying a state-changing call.

These flaws usually sit behind a login or a partner trust boundary, so authenticated testing is essential. Probe only anonymous endpoints and you miss the paths that can reach essential services, sensitive records and downstream operational systems.

Choose a method auditors can trust and engineers can repeat

Black-box, gray-box and white-box

Black-box testing gives realism, gray-box gives speed, white-box gives depth. For high-criticality or complex internal APIs, white-box is often the better call, because the hardest problems hide in schemas, authorization logic and service-to-service trust paths.

Run a repeatable sequence: discovery, authentication setup, attack-surface review, exploitation attempts, impact validation, reporting and retest. The report becomes defensible when the same sequence can be run again after remediation and produce comparable results.

Standards worth naming in the report

The OWASP API Security Top 10, the OWASP Application Security Verification Standard (ASVS) and the OWASP Web Security Testing Guide (WSTG) strengthen the methodology, because they tie the test to recognised expectations rather than a one-off consultant checklist.

My default for NIS2 APIs is authenticated gray-box testing, with white-box reserved for the riskiest services. For a comparison of the tooling behind each approach, see our guide to API penetration testing tools.

Turn findings into NIS2 evidence, not just a technical report

What the evidence chain should contain

The chain has to be explicit: scope and authorization, methodology, findings with severity, remediation plan, retest and sign-off. As APIPentest's guide to DORA, NIS2 and PCI DSS testing puts it, the record should show the date, the scope, the identity and independence of the tester, the findings, what was fixed and when, and the retest that confirmed it. That is the structure an auditor can review without guessing what happened between the engagement and the ticketing system.

How to map findings to Article 21

Map findings to Article 21 themes, not only to CVEs or OWASP labels:

  • Broken authorization points to gaps in access control, secure development and maintenance, and possibly logging.
  • Injection touches secure coding and vulnerability handling.
  • A missing token revocation check points to access control and identity assurance.

Each finding in the report should then carry the same fields: API or service, risk scenario, finding, business impact, Article 21 measure, owner, due date and retest status. That format tells engineering what to fix and gives the compliance lead a direct line from flaw to control. The retest and sign-off line is the one that proves effectiveness, so it is the one auditors read first.

This is where most reports break. Fleuret runs agentic pentests on web apps, REST and GraphQL APIs and external infrastructure, with results in hours, replayable proofs of concept and a DORA and NIS2 mapping on every finding. Findings go straight to Jira, Linear or Slack, the retest runs after the fix, and a signed report is available on demand.

Remediation speed matters more than finding volume

How to prioritise API findings

A handful of exploitable authorization flaws can matter more than dozens of medium misconfigurations, because the business impact is direct. Prioritise by exploitability, data sensitivity, blast radius, and whether the API supports an essential service.

That model is easy to defend in an audit because it explains why some issues were fixed first. It also stops the team from spending weeks on low-value noise while a partner API still allows account takeover or cross-tenant access.

When to retest

Treat the retest as part of the engagement, not a courtesy. CodiTrust, for instance, includes it in its NIS2 offer because the retest completes the technical evidence file. Without it, you only have an intention to fix.

A practical timeline: critical findings fixed in days, highs within weeks, and the retest scheduled before the internal compliance review. That keeps the Article 21 evidence current.

Build API pentesting into a year-round NIS2 program

When to test

  • After major releases. New code often changes authorization logic, object handling or rate limits.
  • After authentication changes. Any change to JWT rules, roles, scopes or partner trust boundaries can open new attack paths.
  • After new integrations. Third parties and processors widen exposure faster than teams expect.
  • When the API shape changes. A new OpenAPI spec, a new public endpoint, a change to the permission model or a migration to GraphQL should trigger a review.

What to automate between tests

  • API inventory, so testing starts from the real estate, not last quarter's list.
  • Schema drift checks, to catch endpoints and fields that appear outside approved releases.
  • Authorization policy reviews, to confirm roles, scopes and claims still match the intended model.
  • Logging validation, to confirm key security events are actually recorded.
  • Exposure monitoring, for internet-facing endpoints, stale versions and test environments that leaked into production.

Regular assessment is what Article 21 implies, so an annual pentest alone is weak for APIs that change every week.

The mistakes that make "NIS2-ready" pentests fail

Testing mistakes

  1. Testing only the public docs leaves partner, admin and old-version APIs untouched.
  2. Skipping authenticated roles misses the flaws behind login and service trust boundaries.
  3. Leaving out business-logic abuse cases produces a report that looks technical but misses the attacks that change outcomes.
  4. Omitting the retest turns a pentest into a discovery exercise rather than compliance evidence.

Documentation mistakes

  1. No explicit scope approval makes the engagement hard to defend later.
  2. No mapping to controls leaves auditors guessing how findings relate to Article 21.
  3. No owner on each finding slows remediation and blurs accountability.
  4. No evidence that fixes were validated leaves the report incomplete.

Rushed engagements create gaps, and the first thing to disappear when time runs short is usually the retest. Before you commission or review an API pentest, check four things: scope approved, authenticated coverage planned, remediation owners assigned, retest booked. If one is missing, you are buying a test, not NIS2 evidence.

What I recommend

Commission your next API pentest as evidence work, not a security checkbox. Start with the highest-impact APIs, insist on authenticated testing and a retest, and require the final package to map cleanly to Article 21. If a vendor cannot show how findings become proof, keep looking.

Fleuret runs agentic API pentests that come back in hours with replayable PoCs, NIS2 mapping, tickets and a retest after the fix.

See Fleuret in action.

Sources

Share this postShare on LinkedIn
TRY IT ON YOUR APP

Scan your own code, free.

The Free plan runs SAST, DAST, SCA and secret scanning for 2 users and 10 repos, no call needed. Several apps or an audit deadline? Book a demo instead.

Start freeBook a demo