In this guide, we break down the main types of penetration testing by target: web applications, APIs, mobile apps, SaaS products, cloud infrastructure, internal and external networks, IoT devices, AI applications, and more.
We’ll also clarify terms buyers often mix into the same conversation, such as black box, gray box, white box, manual testing, and automated testing. These are not pentest types in the same sense. They describe the pen tester’s perspective and methodology.
By the end, you should understand which assessment fits your environment, what each test is designed to uncover, how compliance requirements fit into it, and how to avoid scoping the wrong engagement.
What is penetration testing?
Penetration testing is a controlled security assessment where ethical hackers attempt to identify and validate vulnerabilities before real attackers can exploit them.
A real pentest does more than uncover security vulnerabilities. It shows whether those security weaknesses can be exploited, what impact they could have, how they could be chained, and which issues matter most from a business-risk perspective. A security scan might tell you that something looks vulnerable. A penetration test tells you whether it can be abused, how far an attacker could go, and what to fix first.
How to choose the right type of penetration test
The right pentest starts with the right scope. Too narrow, and you miss the risk that matters. Too broad, and you waste time testing assets that are not relevant to your actual threat model.
Most scoping conversations come down to five questions:
What is most exposed right now? What systems handle sensitive data? What does compliance or customer due diligence require? What changed recently in your product or infrastructure? And what outcome do you need: vulnerability discovery, audit evidence, executive assurance, or detection-and-response validation?
Use the table below as a starting point.
|
Your situation |
Recommended penetration test |
|---|---|
|
You have a SaaS product |
SaaS pentest, usually combining web application, API, cloud, and external network testing |
|
You have a web application |
Web application penetration testing |
|
You expose APIs to customers, partners, mobile apps, or internal systems |
API penetration testing |
|
You have an iOS or Android app |
Mobile application penetration testing, usually combined with API testing |
|
You host infrastructure in AWS, Azure, GCP, or another cloud provider |
Cloud penetration testing and/or cloud security review |
|
You want to test internet-facing assets |
External network penetration testing |
|
You want to understand what an attacker could do after gaining internal access |
Internal penetration testing or assumed breach testing |
|
You are preparing for SOC 2, ISO 27001, PCI DSS, or customer due diligence |
Compliance-driven penetration testing based on the relevant systems in scope |
|
You release frequently and need ongoing visibility |
Penetration Testing as a Service (PTaaS) or recurring pentesting |
|
You want to test detection, response, and realistic attack paths |
Red teaming or assumed breach assessment |
|
You build connected devices or embedded systems |
IoT penetration testing |
|
You are building AI agents, copilots, or RAG-based applications |
AI / LLM application penetration testing |
Different penetration tests reveal different risk patterns
Choosing the right type of penetration test matters because different assessments expose different kinds of risk.
A web application or API test is more likely to uncover broken access control, business logic flaws, and sensitive data exposure. A cloud or internal network infrastructure test may reveal privilege escalation paths, exposed assets, weak segmentation, or IAM misconfigurations. An IoT or AI application assessment often exposes issues around local components, unsafe integrations, trust boundaries, and how systems behave when attackers manipulate inputs or workflows.
That does not mean each pentest type maps neatly to one vulnerability category. Real findings often overlap, and the most serious issues are frequently chained across systems; however, what you choose to test strongly influences what you are able to find.
This is also reflected in Blaze’s real-world testing data. In our Annual Penetration Testing Review 2025, we analyzed cybersecurity assessments we performed last year. The data shows why penetration testing should be scoped around actual attack surfaces, and what types of risks each type of pentest reveals.
Testing perspective: black box, gray box, and white box
One of the most common categorizations of penetration tests is based on the volume of information that has to be shared by the company with the penetration testing provider prior to the engagement. Depending on how much information the penetration testers are given, they will perform the assessment from one of the following perspectives:
White-box penetration testing
In white-box penetration testing (also called full-knowledge penetration testing), the security engineers have full access to the target scope, which may include credentials, network diagrams, documentation, and source code. It allows them to thoroughly analyze the system and identify any weak points from the vantage point of a complete insider.
It is typically one of the most time-consuming penetration tests, as it requires sifting through a large volume of information. However, it allows organizations to discover and fix issues that may not be apparent to an average hacker but still might be exploited by a malicious insider.
Black-box penetration testing
Black-box penetration testing, or zero-knowledge pentesting, doesn’t arm the security engineer with any prior knowledge about the systems under the scope. The assessment is performed from the perspective of an attacker who only has publicly available data at their disposal. This type of pentest can be useful for identifying security vulnerabilities and simulating a complete external attacker.
Gray-box penetration testing
Gray-box pentesting, also called insider attack simulation, is a hybrid approach in which the penetration tester has some prior knowledge of the system but not complete access. For instance, in web application pentesting, it is common to provide the testing team with a set of test credentials – this is considered a gray-box approach.
This type of pentest can be useful for identifying both technical and organizational vulnerabilities and is usually more focused than a black-box method. It allows the cybersecurity engineer to thoroughly assess systems that are critical to the organization while still exposing the danger that external hackers may pose. It is also the most common pentesting perspective.
There are benefits to all three types of perspectives. However, most penetration tests take place from either a grey-box or white-box point of view.
Testing methodology: manual vs automated penetration testing
Manual and automated testing describe how the assessment is performed, not what is being tested.
Automated tools are useful. They help with discovery, coverage, repeatability, known CVEs, common misconfigurations, exposed services, weak TLS settings, outdated software, and some classes of application security issues. However, automation is not a substitute for a real penetration test.
Manual testing is where experienced pentesters validate impact, chain vulnerabilities, abuse business logic, test authorization boundaries, escalate privileges, and understand risk in context. These are exactly the areas where scanners are weakest.
The best assessments use automation where it helps and human expertise where it matters. If your goal is customer assurance, compliance evidence, or meaningful risk reduction, a manual-led penetration test is almost always more valuable than an automated scan alone. For more information on what the so-called automated pentests really are (often they are closer to vulnerability scanning), check out our blog post on the subject.
Main types of penetration testing
The main penetration testing types are usually defined by the asset, environment, or attack surface in scope. That is the most useful way for buyers to think about them.
Web application penetration testing
Web application penetration testing assesses the security of browser-based applications, customer portals, admin panels, dashboards, and other web systems.
This is one of the most common pentest types for SaaS companies, fintech platforms, healthcare portals, e-commerce websites, and internal business applications.
A web app pentest typically covers authentication, session management, authorization, input validation, business logic, access control, sensitive data exposure, and OWASP Top 10 risks such as cross-site scripting, SQL injection, server-side request forgery, insecure file uploads, and broken access control.
In practice, the most meaningful web application findings are rarely limited to simple injection bugs or scanner-detected issues. They often appear in user workflows, role boundaries, tenant separation, admin functionality, business rules, and API interactions behind the interface.
That is why web application penetration testing should usually be authenticated and manual-led. If a pentester cannot exercise real user roles and workflows, they will miss the risks that matter most.
API penetration testing
API penetration testing focuses on REST APIs, GraphQL APIs, SOAP services, gRPC endpoints, microservices, and other machine-to-machine interfaces.
APIs are now one of the dominant attack surfaces for SaaS and B2B platforms. They power mobile apps, integrations, partner ecosystems, internal services, and customer-facing products. When API authorization fails, it enables malicious users to access sensitive data or perform privileged actions.
A strong API pentest looks for issues such as broken object-level authorization, broken function-level authorization, weak authentication, excessive data exposure, mass assignment, injection vulnerabilities, rate limiting problems, and business logic abuse.
API testing is especially effective when penetration testers understand the intended relationships between users, objects, tenants, roles, and business actions. That is why good API scoping usually includes OpenAPI or Swagger files, Postman collections, sample requests, authentication details, and role-specific test accounts.
Mobile application penetration testing
Mobile application penetration testing evaluates Android and iOS applications, the data they store, the way they communicate, and the backend APIs they rely on.
A mobile pentest does not stop at the app binary. It should also assess local storage, certificate validation, authentication flows, cryptography, inter-app communication, reverse engineering risk, tampering resistance, hardcoded secrets, and the security of backend API calls.
This is critical for fintech, healthcare, mobility, marketplaces, IoT companion apps, and any consumer-facing product that handles sensitive user data.
Mobile apps often expose API and authorization weaknesses that are not obvious from the web interface. For that reason, mobile application testing is usually strongest when paired with API testing.
SaaS penetration testing
SaaS penetration testing assesses a software-as-a-service product as a complete business system and typically combines web application testing, API testing, cloud testing, external network security testing, and sometimes mobile or desktop client testing. The exact scope depends on how the product is built and where customer data flows.
The areas that matter most are often tenant isolation, role-based access control, customer data exposure, authentication and session handling, API authorization, admin or support tooling, SSO and OAuth flows, audit logs, integrations, webhooks and cloud storage.
For SaaS companies, risk often sits between systems. A broken authorization rule in the web app, an overly permissive API endpoint, a misconfigured cloud bucket, or weak tenant isolation can all lead to customer data exposure. That is why SaaS pentesting should be scoped around architecture and data flows, not just the front-end application.
Cloud penetration testing
Cloud penetration testing evaluates cloud-hosted systems, identity configurations, storage permissions, network exposure, workloads, managed services, containers, serverless functions, secrets, and cloud-native attack paths.
This is not just traditional infrastructure testing moved into AWS, Azure, or Google Cloud. Cloud environments introduce different risks: IAM misconfigurations, overly permissive roles, exposed storage, metadata service abuse, insecure security groups, public snapshots, weak logging, CI/CD secrets, and Kubernetes or container misconfigurations.
Cloud deserves its own scope. In Blaze’s 2025 penetration testing dataset, cloud security assessments had the highest average vulnerability density of any assessment type, with 14.40 vulnerabilities per project. That is a strong signal that cloud risk is often underestimated during scoping.
Cloud pentesting is especially relevant for SaaS companies, cloud-native startups, enterprises migrating workloads, and organizations preparing for SOC 2, ISO 27001, PCI DSS, or enterprise customer reviews.
External penetration testing
External network penetration testing assesses systems reachable from the public internet. This includes public IP ranges, VPN gateways, exposed servers, mail and DNS infrastructure, remote access systems, cloud-hosted services, forgotten subdomains, and internet-facing admin interfaces.
The question external testing answers is simple: what can an attacker reach from the internet?
Findings may be fewer than in an internal test, but they can be extremely high-impact. An exposed management panel, outdated VPN appliance, misconfigured cloud service, or vulnerable public-facing host may be enough to create an entry point into the organization.
External pentesting is a strong fit for companies that want to validate perimeter security, reduce exposed attack surface, prepare for customer due diligence, or understand what a motivated attacker can discover without internal access.
Internal network penetration testing
Internal network pentesting simulates an attacker who has already gained access to the internal environment. That access may represent a compromised laptop, stolen VPN credentials, a malicious insider, a successful phishing attack, or an infected endpoint.
The question internal testing answers is: what could an attacker do after gaining a foothold?
Internal network pen tests often focus on Active Directory, Kerberos, privilege escalation, lateral movement, weak internal services, file share permissions, exposed credentials, network segmentation, insecure administrative practices, and access to sensitive systems.
This type of pentest is often where organizations discover the real blast radius of a compromise. External testing shows how an attacker may get in. Internal testing shows how far they could go.
Wireless penetration testing
Wireless penetration testing usually means Wi-Fi security testing, although it can also include Bluetooth, BLE, Zigbee, or other radio protocols when relevant.
A wireless pentest validates whether wireless networks are properly authenticated, segmented from sensitive systems, and resistant to attacks such as evil twin access points, weak WPA2/WPA3 configurations, captive portal abuse, credential capture, and insecure enterprise authentication.
Wireless testing is especially relevant for offices, warehouses, manufacturing sites, healthcare environments, retail locations, and any site where wireless access could become an entry point into internal systems.
Desktop application penetration testing
Desktop penetration testing, also called thick client penetration testing, assesses compiled desktop applications and the way they interact with backend systems.
These applications are common in financial services, industrial software, healthcare environments, enterprise tooling, and legacy business systems. They may be written in C/C++, .NET, Java, Electron, or other desktop technologies.
Testing often involves reverse engineering, local storage review, memory analysis, update mechanism testing, inter-process communication review, authentication and authorization testing, and backend API analysis.
Common findings include sensitive data left on disk or in memory, hardcoded secrets, weak local encryption, insecure update channels, local privilege escalation paths, and backend trust assumptions that can be abused by modifying the client.
AI and LLM application penetration testing
AI and LLM application penetration testing focuses on applications that use large language models, AI agents, retrieval-augmented generation, plugins, function calling, or model-driven business logic.
This is not just “trying strange prompts.” The real risk usually appears at the boundary between the model and the application: what data the model can access, what tools it can call, what instructions it trusts, and what actions it can trigger.
An LLM pentest may test prompt injection, indirect prompt injection, prompt leaking, data leakage through model responses, excessive agency in tool-using agents, insecure function calls, RAG access control, cross-tenant data exposure, and weak authorization around AI-driven workflows.
For SaaS companies adding copilots, AI assistants, autonomous workflows, or internal agents, LLM testing should usually be combined with web, API, cloud, and authorization testing. AI features rarely exist in isolation.
IoT penetration testing
IoT penetration testing assesses connected devices, embedded systems, firmware, hardware interfaces, communication protocols, companion applications, and cloud backends.
A serious IoT pentest looks at the device as an ecosystem. The hardware may expose UART, JTAG, SPI, or other debug interfaces. The firmware may contain hardcoded credentials, insecure update mechanisms, weak cryptography, or exploitable services. The mobile app and cloud backend may expose API, authentication, or authorization flaws.
IoT pentesting is critical for medical devices, industrial systems, automotive components, consumer electronics, smart-home products, and connected infrastructure.
Social engineering penetration testing
Social engineering pen testing evaluates whether attackers could manipulate employees into revealing information, providing access, approving fraudulent requests, or taking unsafe actions.
Common scenarios include phishing, spear phishing, vishing, smishing, credential harvesting simulations, pretexting, and malicious attachment simulations.
Social engineering attack scenarios are often used as part of red team exercises or broader security awareness programs. It helps test not only employees, but also reporting processes, email security controls, escalation paths, and incident response readiness.
Physical penetration testing
Physical penetration testing simulates an attacker physically accessing a building or location to gain unauthorized access to computer systems or sensitive data. It can include activities such as breaking into a locked facility, bypassing security systems, or “stealing” hardware or data storage devices.
Most organizations that have a physical office, especially containing server rooms, important equipment, or information, can benefit from a physical penetration test.
Assumed breach testing and red teaming
Assumed breach testing starts from the premise that an attacker already has a foothold. Instead of asking whether an attacker can get in, it asks what they can do once they are inside.
This type of assessment often focuses on lateral movement, privilege escalation, Active Directory attacks, cloud privilege escalation, credential theft, access to sensitive data, and gaps in detection or response.
Red teaming goes further. It is not simply a deeper pentest. A red team engagement is usually objective-based and adversarial. The goal may be to access a specific system, reach sensitive data, simulate a realistic threat actor, or test whether the organization can detect, respond to, and contain attack activity.
Red teaming is best suited for organizations with more mature security programs. If a company has not yet addressed standard application, API, cloud, or infrastructure risks, focused penetration testing will usually provide more immediate value.
For regulated financial entities, red team-style exercises may also intersect with frameworks such as TIBER-EU, and TLPT for DORA. Those engagements are more formal than a standard commercial red team and require specific governance, threat intelligence, documentation, and oversight.
Compliance-driven penetration testing
Many companies start looking for penetration testing because of compliance, customer requirements, or third-party risk assessments. That is a valid reason to test, but it should not turn the assessment into a checkbox exercise.
SOC 2, ISO 27001, PCI DSS, HIPAA, GDPR-related security assurance, enterprise customer reviews, vendor risk assessments, and cyber insurance requirements may all influence the need for testing. But the right scope still depends on the systems that store, process, transmit, or provide access to sensitive data.
For example, a SaaS company preparing for SOC 2 may need web application, API, cloud, and external infrastructure testing. A company handling cardholder data may need PCI DSS-aligned testing of the cardholder data environment. A healthcare company may need to prioritize systems that process protected health information.
Blaze’s research also shows that compliance-driven pentests can surface different patterns depending on the framework and scope. SOC 2-driven assessments frequently reveal authenticated access control issues, information exposure, and error message leakage. ISO 27001 assessments often surface issues related to users abusing permissions or roles. PCI DSS assessments may produce fewer findings overall, but a higher share of Critical and High severity issues.
One-time pentest vs recurring testing vs PTaaS
Some companies need a point-in-time assessment before an audit, launch, acquisition, or customer review. Others need a more continuous penetration testing services because their product, infrastructure, and attack surface change every month.
A one-time penetration test may be enough when the system is stable, the scope is clear, and the goal is to validate a specific release or provide audit evidence.
Recurring penetration testing is more appropriate when the product changes frequently, new features are released often, APIs are added regularly, or the company operates in a high-risk or regulated market.
Penetration Testing as a Service (PTaaS), can help teams manage scoping, findings, communication, remediation, retesting, and evidence, such as a penetration testing report, in a more continuous workflow.
Which penetration test does your company need?
The right penetration test depends on what you need to protect and what decision you are trying to make.
|
Company type or goal |
Best starting point |
|---|---|
|
Early-stage SaaS company |
Web application + API pentest, usually gray box or white box |
|
SaaS company preparing for SOC 2 |
SaaS pentest covering web app, API, cloud, and external assets in scope |
|
Fintech company |
Web app, API, cloud, and compliance-aligned testing; often recurring |
|
Company with mobile apps |
Mobile app pentest plus backend API testing |
|
Company with internet-facing infrastructure |
External infrastructure pentest |
|
Company concerned about internal compromise |
Internal pentest or assumed breach assessment |
|
Cloud-native company |
Cloud penetration test or cloud security review |
|
Mature security team |
Red team or assumed breach assessment |
|
Hardware or connected device company |
IoT penetration test |
|
Company building AI agents or copilots |
LLM application pentest combined with web/API/cloud pen testing |
|
Company preparing for customer due diligence |
Scope based on customer-facing systems and data flows |
If you are unsure, start with the assets that carry the highest business risk: customer-facing applications, APIs, systems that store sensitive data, cloud environments, and identity systems.
Conclusion
There is no single best type of penetration test for every company. The right choice depends on your architecture, attack surface, compliance requirements, threat model, maturity level, and business goals.
For many modern companies, especially SaaS and technology businesses, the right scope combines web application, API, cloud, and external infrastructure testing. Companies with mobile apps, internal networks, IoT devices, AI features, or mature detection programs may need additional assessments such as mobile pentesting, internal testing, IoT testing, LLM testing, assumed breach testing, or red teaming.
The strongest penetration testing programs do not treat testing as an annual checkbox. They scope assessments around real attack surfaces, validate business impact, retest remediation, and adjust testing frequency as products, infrastructure, and compliance requirements evolve.
If you are not sure which test fits your environment, the answer is not to buy the broadest package. The answer is to scope the engagement around the systems, data, and attack paths that matter most.
Not sure which penetration test fits your environment?
Talk to us. We’ll help you map your applications, APIs, cloud infrastructure, and business risks to the right assessment.
