Penetration testing services

Make vulnerabilities visible

A penetration test is a controlled security assessment that simulates realistic attack techniques within an agreed scope and predefined rules of engagement. It exposes weaknesses that are not yet known, not yet understood or not yet proven exploitable. The objective is not to produce a list of scanner findings. It is to determine where security controls fail, which attack paths become available and how far a capable attacker can progress.

Automated discovery supports coverage and helps identify known vulnerabilities, exposed services and configuration weaknesses. Manual testing then establishes whether those findings can be exploited, chained or used to cross trust boundaries. Systems, identities, privileges, configurations and business logic are assessed as one connected environment rather than as isolated components. The assessment results in a clear operational picture of the attack surface. Findings are supported by technical evidence of exploitability, impact and likelihood, allowing remediation to focus on the weaknesses and attack paths that create the greatest actual risk.

DeepBlue is CCV Pentest certified

Validate security under realistic attack conditions

A penetration test must establish what can actually be exploited. Applications, APIs, cloud platforms, internal networks, external infrastructure, identity environments, OT systems and mobile applications are assessed from the perspective of a capable attacker. Testing remains controlled through predefined rules of engagement, escalation procedures and technical boundaries.

The assessment shows which weaknesses can be used to gain access, escalate privileges, cross trust boundaries or reach sensitive systems and data. It also shows how individual findings can be combined into a viable attack path. This provides evidence of the potential impact on operational continuity, information security and critical business processes.

The increasing use of AI in software development, cloud engineering and automation adds another layer of risk. AI can accelerate delivery, but it does not understand security architecture, operational dependencies or business context unless these are explicitly defined. This can lead to insecure design decisions, excessive permissions, missing validation and security controls that are weakened or bypassed.

Executive stakeholders receive a clear assessment of impact, likelihood and remediation priority. Technical teams receive reproducible findings, evidence of exploitability and concrete remediation guidance. Findings are scored using the CVSS method and interpreted within the technical and operational context of the environment.

Periodic penetration testing supports assurance under frameworks such as NIS2, DORA, ISO 27001 and sector-specific standards. It does not demonstrate compliance by itself. It provides independent technical evidence that security controls remain effective under realistic attack conditions.

Attack surfaces we test

Every environment presents a different attack surface, trust model and operational risk. The scope and test approach are therefore based on the technologies in use, the relevant threat scenarios and the security controls that must be validated. Testing is led manually and supported by specialist tooling where this improves discovery, coverage or technical analysis. The objective is not to complete a standard checklist. It is to identify vulnerabilities, logic flaws and connected attack paths that could provide access to systems, identities, sensitive data or critical processes.

OWASP · REST · GraphQL

Web applications & APIs

Web applications and APIs often provide the shortest route to business data and critical functionality. Testing covers authentication, authorisation, session management, input handling, file processing, API security and business logic. Specific attention is given to weaknesses that cross user roles, tenants, workflows or trust boundaries.

Attack method

Account takeover, broken access control, Object Level Authorizations, IDOR, SSRF, injection or abuse of application logic to access restricted data and functionality.

Tools, techniques and procedures

Burp Suite Pro

Caido

Postman

GraphQL Voyager

jwt_tool

Custom scripting

Microsoft Entra · AWS · Google Cloud

Cloud environments

Cloud attack paths commonly originate from excessive permissions, exposed services, leaked secrets and unintended trust relationships. Testing covers IAM, storage, workloads, service principals, roles, network controls and hybrid integrations. Permissions are analysed as connected paths rather than isolated configuration settings.

Attack method

Credential or token compromise, resource enumeration, role chaining, privilege escalation and unauthorised access to cloud workloads or sensitive data.

Tools, techniques and procedures

ScoutSuite

Custom Tooling

CloudFox

Prowler

Trufflehog

Steampipe

Active Directory · Kerberos · AD CS

Internal networks

Internal network testing establishes how far an attacker can progress from a workstation, user account, server or assumed foothold. Active Directory, administrative interfaces, network segmentation, certificate services, trust relationships and backup infrastructure receive specific attention.

Attack method

Credential interception, password reuse, SMB relay, Kerberos abuse, AD CS exploitation, lateral movement and escalation towards domain-level control.

Tools, techniques and procedures

BloodHound

Impacket

Certipy

NetExec

Responder

Rubeus

Recon · Edge

Externe infrastructuur

Internet-facing infrastructure changes as domains, systems, cloud services and third-party platforms are introduced or retired. Testing maps exposed assets, services, subdomains, edge devices and remote-access interfaces. Potential weaknesses are manually validated before they are reported.

Aanvalsmethode

OSINT and attack-surface discovery identify forgotten assets, vulnerable edge systems or exposed administration services that provide an initial foothold.

Tools, technieken en procedures

Amass

Subfinder

Nuclei

Nmap

Shodan

Censys

Microsoft Entra ID · Active Directory · Okta

Identity & Access

Identity platforms form a primary security boundary in modern environments. Testing covers authentication, federation, MFA enforcement, Conditional Access, device trust, application consent, privileged roles and administrative workflows. The assessment traces how identities, tokens and permissions can be combined into broader attack paths.

Attack method

Credential theft, token replay, device-code phishing, OAuth consent abuse, Conditional Access bypass and privilege escalation towards tenant or domain admin.

Tools, techniques and procedures

ROADTools

Bloodhound

Custom Tooling

IEC 62443 · ICS · SCADA

OT environments

OT environments require a controlled test approach that accounts for process availability, equipment behaviour and physical safety. Assessments focus on the IT-to-OT boundary, zones and conduits, remote access, engineering workstations, industrial protocols and communication between Purdue levels.

Attack method

Reverse engineering, token extraction, certificate-pinning bypass, hardcoded secrets or abuse of backend interfaces leading to account or data compromise.

Tools, techniques and procedures

Wireshark

Zeek

OT NSE-scripts

OPC UA-tooling

Modbus-tooling

Passive asset discovery

iOS · Android · Thick Client

Mobile & Client Applications

Mobile and desktop applications can expose sensitive logic, credentials, tokens and direct interfaces to backend services. Testing covers local storage, authentication, transport security, inter-process communication, reverse engineering, client-side controls and server-side integrations.

Attack method

Compromise of corporate IT, movement through shared services or remote-access infrastructure and unauthorised communication with engineering stations, HMIs, PLCs or SCADA systems.

Tools, techniques and procedures

Frida

MobSF

jadx

Ghidra

dnSpy

Sectors we test

Every sector has its own threat model, operational dependencies and regulatory context. A penetration test must therefore reflect the systems that matter, the attack paths that are realistic and the consequences of compromise within that environment. The scope, test method and rules of engagement are adapted to the sector. This ensures that testing remains technically relevant, operationally controlled and aligned with the security requirements that apply.

NEN 7510 · NIS2 · NEN 7512

Healthcare

Healthcare environments combine electronic health records, medical devices, diagnostic systems, identity platforms and external care integrations. Testing focuses on attack paths that could affect patient safety, confidentiality or continuity of care. Access control, segmentation, medical IoT, privileged access and system integrations receive specific attention.

Attack method

Phishing healthcare staff, accessing healthcare systems, moving laterally through the environment and gaining unauthorised access to patient data or medical devices.

View sector →

DORA · TLPT / TIBER-EU · SWIFT CSP · PCI DSS

Financial Services

Financial institutions depend on the integrity and availability of payment systems, customer portals, APIs, identity services and third-party connections. Testing focuses on fraud scenarios, account takeover, transaction manipulation, privileged access and compromise of critical financial processes.

Attack method

Targeted credential compromise, account takeover, privilege escalation and access to transaction systems, followed by manipulation of financial processes or data.

View sector →

BIO2 · ABDO · NIS2 · ISO 27001

Defence & Government

Government and defence environments contain sensitive information, public services, mission systems and complex supply-chain dependencies. Testing is performed within formal rules of engagement and with strict control over access, evidence handling and operational risk. Scopes may include public-facing platforms, internal networks, secure environments and critical IT or OT systems.

Attack method

Compromise of a public-facing system or external identity, followed by lateral movement and access to sensitive information, administrative systems or mission-supporting infrastructure.

View sector →

IEC 62443 · NIS2 · ISO 27001 · Cyber Resilience Act

Manufacturing

Manufacturing environments combine industrial automation, corporate IT, intellectual property and time-critical production. Testing focuses on IT-to-OT attack paths, remote access, engineering workstations, industrial networks and production management systems. Non-disruptive methods are applied where process availability and safety impose strict limits.

Attack method

Compromise of the corporate environment, movement through shared services or remote-access infrastructure and unauthorised interaction with engineering systems, HMIs, PLCs or production platforms.

View sector →

IEC 62443 · NIS2 · ISO 27019 · CER Directive

Energy & Critical Infrastructure

Energy and critical infrastructure rely on distributed operational systems, remote sites and continuous process control. Testing focuses on segmentation, remote access, industrial communication, management environments and the interfaces between IT and OT. The rules of engagement account for high availability requirements and possible physical consequences.

Attack method

Access through a supplier, remote location or corporate environment, followed by movement towards operational systems and manipulation of monitoring, control or safety-related processes.

View sector →

NIS2 · ISO 27001

Logistics & Transport

Logistics and transport depend on planning systems, warehouse automation, fleet technology, tracking platforms and integrations with external partners. Testing focuses on identities, customer and partner portals, operational data, segmentation and supply-chain access. Integrity and availability receive the same attention as confidentiality.

Attack method

Compromise through a portal, supplier or partner account, followed by manipulation of scheduling, tracking or cargo information and disruption of operational processes.

View sector →

ISO 27001 · SOC 2 · NIS2 · OWASP ASVS

IT & Technology

Technology providers operate multi-tenant platforms, cloud infrastructure, APIs, CI/CD pipelines and privileged management systems. A single compromise may affect multiple customers or downstream organisations. Testing focuses on tenant isolation, privilege boundaries, software supply-chain risk, administrative access and platform resilience.

Attack method

Compromise of an administrative interface, CI/CD identity or tenant boundary, followed by access to customer data, production infrastructure or shared platform services.

View sector →

Penetration test models and depth

The appropriate test model depends on the question the assessment must answer. Black box testing evaluates what an external attacker can identify and exploit without prior knowledge. Grey box testing combines realistic attacker behaviour with enough context to examine security controls in greater depth. White box testing provides broad technical visibility into architecture, configuration and implementation. Threat-led penetration testing evaluates resilience against defined adversary scenarios.

The objective is established before the test begins. This may include validating the public attack surface, assessing risk from an authenticated user, reviewing security-critical implementation choices or determining whether detection and response controls recognise realistic attack activity. The objective determines the scope, required access, depth of testing and reporting structure.

Grey box testing is the preferred model for most assessments. Access to selected accounts, roles, network segments or architecture information allows more time to be spent validating controls and tracing attack paths. External reconnaissance remains part of the operation, preserving visibility of the attack surface while providing greater technical coverage than a black box assessment.

Scope, objectives, rules of engagement, test windows, stop conditions and escalation procedures are documented before active testing begins. This keeps the operation controlled and protects production continuity while providing sufficient freedom to investigate and validate realistic attack paths.

Black box

Testing begins without credentials, documentation or architectural context. The assessment establishes what an unknown external attacker can discover and exploit from publicly accessible systems. It provides insight into external exposure, initial-access routes and weaknesses visible from outside the environment.

Grey box

Testing is performed with limited context, such as user accounts, defined roles, network access or selected architecture information. This allows deeper testing of authenticated functionality, privilege boundaries and internal attack paths while retaining a realistic attacker perspective. Grey box is generally the most effective model for web applications, cloud platforms, identity environments and internal networks.

White box

Testing is performed with extensive technical context, including source code, configurations, architecture documentation and privileged accounts where relevant. This model provides the greatest technical coverage and supports detailed analysis of design decisions, trust boundaries, implementation flaws and security controls.

TLPT

Testing is based on realistic threat scenarios derived from the sector, critical assets and relevant adversary techniques. The operation can include people, processes, technology, detection and response. Threat-led penetration testing is intended for organisations with advanced resilience requirements and can align with frameworks such as TLPT and TIBER-EU.

Frequently asked questions about penetration testing

What is the difference between a penetration test and a vulnerability scan?

A vulnerability scan uses automated tooling to identify known vulnerabilities and configuration weaknesses. A penetration test adds manual analysis, exploitation and attack-path validation. It determines whether a weakness can be used in practice, how separate findings can be chained and what level of access or impact an attacker could achieve.

Which systems can be included in a penetration test?

The scope can include web applications, APIs, mobile applications, external infrastructure, internal networks, Active Directory, Microsoft Entra ID, cloud environments, wireless networks, endpoints and OT environments. Combined scopes can be used to examine attack paths across applications, identities, infrastructure and network boundaries.

What is the difference between black box, grey box and white box testing?

A black box test starts without credentials or internal documentation. A grey box test uses limited access or technical context to test authenticated functionality and internal attack paths in greater depth. A white box test includes extensive information such as source code, architecture and configurations. Grey box testing provides the strongest balance between realistic attacker behaviour and technical coverage for most assessments.

Can a penetration test be performed safely in production?

Yes, provided that the scope, rules of engagement, stop conditions and escalation procedures are defined in advance. Techniques that could affect availability are restricted or coordinated separately. OT, healthcare and other safety-critical environments require additional controls and may rely on passive analysis or carefully selected active tests.

How long does a penetration test take?

Duration depends on the size, complexity and required depth of the scope. A limited application or infrastructure assessment may require one or a few test days. Complex environments with multiple roles, networks, cloud platforms or OT systems may require several days up to one or more weeks. The required effort is established during technical scoping during the intake call.

What does a penetration test report contain?

The report contains the agreed scope, methodology, validated findings, affected assets, technical evidence, attack paths, impact analysis and remediation guidance. Findings are scored using CVSS v4 and interpreted within the operational context of the environment. Critical findings are communicated during the test rather than held until final reporting.

Direct access to senior cybersecurity expertise

Discuss a security requirement, active risk or complex IT or OT environment with one of our senior specialists. The initial conversation focuses on the technical context, operational constraints and the most appropriate course of action.