API Pentesting for NIS2 Compliance and Audit Evidence

API pentesting for NIS2 compliance needs 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 afterward. The audit question is simple: can you prove that the testing was scoped to business-critical exposure, that the highest-risk issues were remediated, and that the retest confirms the control is effective?

Key takeaways

• A NIS2-relevant API pentest is evidence of control effectiveness, not compliance by itself.

• Scope should start with APIs that expose identity, partner access, or operational data, not just the public documentation.

• The most important findings are usually authorization and authentication failures, especially Broken Object Level Authorization.

• Auditor-ready output needs scope approval, findings, remediation ownership, retest results, and a traceable link to Article 21 controls.

• Key Takeaways

A pentest supports NIS2 only if it proves control effectiveness

What NIS2 expects from testing

Article 21 of Directive (EU) 2022/2555 requires cybersecurity risk-management measures, and testing is one of the clearest ways to show those measures are working. ENISA’s 2025 Technical Implementation Guidance, aligned with Implementing Regulation (EU) 2024/2690, is the current technical anchor for turning that legal duty into controls you can test, repeat, and defend in review.

That means the test is not the goal. The goal is proof that your access control, secure development, logging, vulnerability handling, and incident readiness are effective on the APIs that matter most.

“A standard pentest identifies vulnerabilities. A NIS2 compliance pentest answers a different question: which measures of article 21 are technically insufficient, and how to prove it?” — CodiTrust, https://www.coditrust.com/pentest-conformite-nis2

What a pentest can and cannot prove

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

The auditor-friendly claim is narrower and stronger: “We independently tested internet-facing and partner APIs handling identity and operational data, remediated critical issues, and verified fixes by retest.” That is evidence. It is also the right size of claim for a regulator.

Start with scope: map APIs to critical services and data

Which APIs belong in the first wave

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

How to avoid blind spots

• Review Swagger or OpenAPI files first. They expose endpoints, parameters, and object shapes quickly, which gives you a real target list instead of a guessed one.

• Include hidden surfaces. Forgotten endpoints, shadow APIs, old versions, and GraphQL schemas left exposed in production often matter more than the public portal.

• Track owners and environments. If you cannot say who owns the API, where it runs, and what data it touches, the scope is not audit-ready.

• Prioritize exposure over size. A small partner API that handles credentials can deserve earlier testing than a larger but low-risk internal service.

Fleuret helps teams keep an auditable inventory of APIs, owners, environments, and evidence so scope is driven by real exposure rather than spreadsheet drift. That matters when the API estate changes faster than the GRC register.

Test the API risks that matter most under NIS2

Authorization and identity flaws

The center of gravity is the OWASP API Security Top 10, especially Broken Object Level Authorization, broken authentication, mass assignment, and injection. Source 1 and Source 6 both put these at the top for a reason: they map directly to real-world compromise paths, not just theoretical weakness classes.

JWT testing should cover signature integrity, expiration, and revocation, because token weaknesses can turn into identity spoofing. GraphQL introspection left enabled in production is another high-value exposure, since it can reveal the full schema and make the rest of the attack path much easier.

A micro-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.

“Broken Object Level Authorization (BOLA) is the most frequent and dangerous vulnerability for modern APIs.” — OWASP, https://web.keyrus.com/opsky-blog/how-to-pentest-api

Input handling and business logic abuse

Input validation still matters, but for NIS2-relevant APIs you should care more about abuse that changes outcomes. That includes mass assignment, parameter tampering, insecure deserialization, injection, and workflow manipulation such as skipping approvals or replaying state-changing calls.

These flaws often sit behind login or partner trust boundaries, which is why authenticated testing is usually essential. If you only probe anonymous endpoints, you miss the paths that can affect 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 trade-offs

Black-box testing gives you realism, gray-box testing gives you speed, and white-box testing gives you 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.

Use a practical sequence: discovery, authentication setup, attack-surface review, exploit attempts, impact validation, reporting, and retest. The report becomes defensible when the method is repeatable and the same sequence can be run again after remediation.

Standards worth naming in the report

OWASP API Top 10, OWASP ASVS, and OWASP WSTG strengthen the methodology because they show the test is tied to recognized security expectations rather than a one-off consultant checklist. The verdict is simple: authenticated gray-box testing is usually the best default for NIS2 APIs, with white-box reserved for the riskiest services.

Turn findings into NIS2 evidence, not just a technical report

What the evidence chain should contain

The evidence chain should be explicit: scope and authorization, test methodology, findings with severity, remediation plan, retest, and sign-off. Sources 2 and 4 converge on this structure, and it is the structure auditors can actually review without guessing what happened between the engagement and the ticketing system.

Map findings to Article 21 themes, not just CVEs or OWASP labels. A broken authorization issue may support control gaps in access control, secure development and maintenance, logging, or incident readiness; injection can touch secure coding and vulnerability handling; a missing revocation check can point to access control and identity assurance. Source 4, Source 6, and Source 7 all support that kind of mapping.

A compact evidence table in the report should look like this: API/service, risk scenario, finding, business impact, Article 21 measure, owner, due date, retest status. That format helps engineering fix the right thing and gives compliance a direct line from flaw to control.

How to map findings to Article 21

Fleuret centralizes remediation evidence, control mappings, owners, and retest status so teams can answer auditor questions without rebuilding the dossier from scratch. That is where the work stops being a report and starts becoming a record.

Remediation speed matters more than finding volume

How to prioritize API findings

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

That model is hard to argue with in an audit because it explains why some issues got fixed first. It also keeps the team from wasting weeks on low-value noise while a partner API still exposes account takeover or cross-tenant access.

When to retest

Source 2 treats retest as part of the engagement, not a courtesy, and that is the right stance. Retesting is evidence that the remediation worked; without it, you only have an intention to fix.

A practical timeline is straightforward: critical findings fixed in days, highs within weeks, and retest scheduled before the internal compliance review. That cadence is usually enough for a well-run team and fast enough to keep the Article 21 evidence current.

Build API pentesting into a year-round NIS2 program

When to test

• Test after major releases. New code often changes auth logic, object handling, or rate limits.

• Test after auth changes. Any change to JWT rules, roles, scopes, or partner trust boundaries can create new attack paths.

• Test after new integrations. Third-party partners and processors often widen exposure faster than teams expect.

• Test when the API shape changes. A new OpenAPI spec, a new public endpoint, a permission model change, or a migration to GraphQL should trigger review.

What to automate between tests

• API inventory. Keep discovery current so testing starts from the real estate, not last quarter’s list.

• Schema drift checks. Detect endpoints and fields that appear outside approved releases.

• Auth policy reviews. Validate that roles, scopes, and claims still match the intended model.

• Logging validation. Confirm that key security events are actually being recorded.

• Exposure monitoring. Watch for internet-facing endpoints, stale versions, and accidental test environments in production space.

Regular evaluation is what Article 21 implies, so annual pentesting alone is weak for APIs that change weekly. Fleuret reduces the scramble before audits by keeping control evidence continuously current, which also narrows the gap between engineering work and compliance reporting.

The common mistakes that make 'NIS2-ready' pentests fail

Testing mistakes

• Testing only the public docs and ignoring the real production surface leaves partner, admin, and old-version APIs untouched.

• Skipping authenticated roles means you miss the flaws that sit behind login and service trust boundaries.

• Leaving out business-logic abuse cases produces a report that looks technical but misses the attacks that actually change outcomes.

• Omitting retest turns a pentest into a discovery exercise rather than compliance evidence.

Documentation mistakes

• Missing explicit scope approval makes the engagement hard to defend later.

• No mapping to controls leaves auditors guessing how the findings relate to Article 21.

• No owner assigned to findings slows remediation and blurs accountability.

• No evidence that fixes were validated leaves the report incomplete.

Source 4’s typical engagement size of 5 to 15 person-days is a useful reminder that rushed work creates gaps. If you are trying to cover everything in a few days, the first thing to disappear is usually the retest.

Before you commission or review an API pentest, check four things: scope approved, authenticated coverage planned, remediation owners assigned, and retest booked. If any one of those is missing, the result is probably a test, not NIS2 evidence.

Make the next test audit-ready from the start

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