Amazon SP-API Penetration Testing Requirements 2026: What Changed?

Expanded Penetration Testing and API Scope in the August 25 Update

Effective August 25, 2026, Amazon updated the SP-API Data Protection Policy, Solution Provider Portal Agreement, and Acceptable Use Policy. Continued use of SP-API after that date means acceptance of the updated agreement and policies.

One of the changes directly affects security testing: Amazon has expanded its vulnerability scanning and penetration testing requirements to explicitly include application programming interfaces (APIs). For organizations that already conduct annual penetration tests, the important question is therefore not simply whether a test was completed, but whether its documented scope covers the systems and applications that process, store, or transmit Amazon information.

This guide explains what changed on August 25, how the current vulnerability management and penetration testing requirements apply to SP-API integrations, and what evidence organizations should retain when demonstrating compliance.

What changed on August 25, 2026

Amazon's announcement is specific about what moved:

Non-compliance with the DPP can affect a solution provider's continued access to SP-API. Organizations should therefore review the full set of updated controls rather than treating penetration testing as an isolated requirement.

This is also not Amazon's first pass at DPP security controls. A November 25, 2025 revision renamed "Developer" to "Solution Provider" and tightened anti-malware controls. August 2026 continues that trajectory rather than starting a new one.

SP-API security requirements at a glance

Amazon classifies the 24-hour incident-notification and 24-hour access-removal requirements under Section 1, so they apply to all Solution Providers. The 7-day Critical and 30-day High vulnerability-remediation deadlines are identified under Section 2 and apply where the Solution Provider stores or processes PII.

Who does this apply to?

Section 1 of the DPP (General Security Requirements) covers every Solution Provider building SP-API applications. If your application authenticates against SP-API at all, Section 1 already binds you. Section 2 (Additional Requirements for PII) layers on top of that when the application performs restricted operations involving personally identifiable information, determined by the SP-API roles it holds. In practice, Section 2 applies when an application performs restricted operations involving PII, and specific applicability should be determined directly from the application's roles and data scope.

The practical question is whether the testing programme meets the applicable cadence and whether the organization can produce evidence if Amazon asks for it. An annual report alone is not enough if its scope omits the SP-API integration, supporting cloud services, Amazon-data stores, or relevant authorization boundaries. Applicability should be confirmed against the current DPP using the application's roles and data scope.

Does your existing pentest actually cover this?

An annual penetration test does not automatically satisfy Amazon's requirement. A report may cover the customer-facing web application while excluding the SP-API integration, supporting APIs, cloud services, or Amazon-data stores. Review the scope and exclusions, then confirm the following:

• What target URLs and hostnames were listed in scope. Customer-facing web app only, or SP-API-facing endpoints named explicitly?
• Authenticated testing with real user roles, or black-box only?
• Any reference to API documentation, OpenAPI/Swagger specs, or endpoint enumeration?
• Were authorization boundaries between roles or seller accounts tested, separately from login and authentication?
• What's under exclusions? That section usually says more than the executive summary.
• Does the test date fall inside the required 365-day window?

If several answers are unclear, treat that as a scoping gap. Resolve it before the next assessment or renewal rather than relying on the report title or executive summary.

What Amazon requires for vulnerability management and penetration testing

Solution Providers must conduct vulnerability scans at least every 30 days, run additional scans after significant network, application, or infrastructure changes, scan code before each release, and complete a penetration test every 365 days using an industry-recognized methodology. For Solution Providers that store or process PII, Amazon also specifies remediation within 7 days for Critical-risk vulnerabilities and within 30 days for High-risk vulnerabilities. Amazon Inspector and SP-API Guard are implementation options; using either tool does not replace the underlying requirements.

Amazon requires penetration testing to cover systems that process, store, or transmit Amazon data, including four broad categories:

• Network infrastructure: public-facing and internal network boundaries, firewalls, routers, switches
• Cloud environments: cloud platforms and their associated services and configurations
• Application-layer assets: web applications, APIs, databases, file or object storage
• Other applicable systems: desktop or mobile applications and other systems relevant to the environment, where applicable

Testing must also assess external-facing components, application functionality, access controls, system configurations, and interfaces. The practical effect for an SP-API integration: scope extends past the UI. A frontend can pass review while the API behind it exposes excessive data, broken authorization between seller accounts, or predictable object identifiers, none of which a UI-only test would catch.

In summary, the penetration test must use an industry-recognized methodology and cover the network, cloud, application-layer, and other applicable systems that process, store, or transmit Amazon data.

A well-scoped SP-API assessment should also examine web-layer authentication and business logic, broken object-level and function-level authorization (BOLA/IDOR), excessive data exposure, OAuth/Login with Amazon implementation and token lifecycle, credentials exposed in logs or client-side code, and secrets management. The final scope should follow the application's architecture and documented data flows.

All Solution Providers must notify Amazon within 24 hours of detecting a security incident and remove access within 24 hours when an employee, contractor, or third party is terminated or changes role. PII-handling applications must also follow the applicable Section 2 retention, restoration, and remediation requirements.

Penetration testing vs. vulnerability scanning

A vulnerability scanner can flag the underlying misconfiguration or outdated component. Whether that weakness can actually be chained into unauthorized access, such as reaching another seller's data through a broken authorization check, is what the manual test is for. Amazon's vulnerability management guidance states this directly: after remediation, solution providers must run a second pen test to validate that identified vulnerabilities have been completely remediated, not just a spot-check of the individual finding.

What evidence should you keep on file?

• Full penetration test report: methodology used, explicit scope statement covering Amazon's four categories
• Testing dates, showing cadence over time rather than one point-in-time event
• Tester identity and qualifications, where applicable
• Endpoints and API surface actually tested, and what was explicitly excluded
• Findings with severity ratings and, where Section 2 applies, the relevant remediation deadlines
• Remediation evidence plus the follow-up penetration test confirming complete remediation
• Vulnerability-scanning records at the 30-day cadence, plus any change-triggered scans
• Code vulnerability scan records tied to release cycles
• Current IMPOC designation
• PII deletion and retention records, where Section 2 applies

Other August 2026 control changes

Penetration testing is only one part of the August 25 update. The revised controls also address web application firewalls, device encryption, screen locking, account lockout, incident-response contacts, credential encryption, and deletion requirements. Each control should be reviewed against the organization's actual systems and data handling.

The Solution Provider Portal Agreement also clarifies obligations for actions performed on behalf of customers and certain insurance requirements. The Acceptable Use Policy adds a quality-and-performance standard and expands the prohibition on circumventing throttling. Use Amazon's current Policies and Agreements page as the authoritative source.

2026 SP-API security readiness checklist

Before your next test:

• Inventory every SP-API application and its owner
• Map SP-API roles held by each application
• Identify where PII is processed (Section 2 applicability)
• Pull your last pentest report and check the actual scope, not just the title

If the scope is unclear, use a structured penetration testing scope checklist before commissioning the next assessment

• Confirm vulnerability scanning cadence is documented at 30 days or less, plus scans after significant changes
• Confirm code scanning runs before releases, not after
• Confirm your pentest scope statement maps to Amazon's four categories: network, cloud, application-layer, and other in-scope systems
• Confirm an IMPOC is designated and reachable

During testing:

• Test authenticated, not just unauthenticated, flows
• Explicitly scope in SP-API-facing endpoints and the OAuth/LWA layer
• Test authorization boundaries between roles/accounts (BOLA/IDOR)
• Document exclusions clearly

After testing:

• Triage findings against the remediation deadlines that apply to the application's data scope
• Remediate, then run the follow-up penetration test Amazon requires to confirm complete remediation
• File the report, remediation evidence, and retest results together
• Map evidence back to the specific DPP requirement it satisfies

 What to do now:

1. Read the current DPP on Amazon's Policies and Agreements page, not just this summary.
2. Determine applicability from your actual SP-API roles and whether PII is in scope.
3. Re-read your last pentest's scope section against the checklist above.
4. Review the other applicable controls, including account lockout, encryption, IMPOC, and data-deletion requirements.
5. Remediate known gaps before your next scheduled test, not during it.
6. Keep evidence on an ongoing basis rather than reconstructing it later.

How RedSecLabs can help

REDSECLABS reviews existing penetration-test scope against Amazon's current SP-API requirements and identifies where APIs, cloud infrastructure, Amazon-data stores, or other in-scope systems were omitted. Where a new assessment is required, testing can cover the web application, APIs, OAuth/LWA, authorization boundaries, cloud configuration, and data storage, followed by remediation validation. Amazon and the Solution Provider remain responsible for the final compliance determination.

Request an Amazon SP-API Pentest Scope Review -> https://calendly.com/redseclabs-info

FAQ

Q1: What changed on August 25, 2026?
Ans: Amazon added a WAF requirement for internet-facing endpoints, full-device storage encryption, a 15-minute screen lock, a 30-minute lockout after 10 failed logins, mandatory IMPOC designation, credential encryption at rest, a 30-day deletion requirement, and expanded vulnerability-scanning and penetration-testing requirements that explicitly include APIs. The Solution Provider Portal Agreement and Acceptable Use Policy changed separately; see the table above.

Q2: Does Amazon require API penetration testing specifically, or just general web app testing?
Ans: Amazon's application-layer scope explicitly includes APIs, alongside web applications, databases, and file/object storage. A UI-only assessment may not satisfy the expanded testing requirements where APIs processing, storing, or transmitting Amazon information are part of the environment.

Q3: Can an existing web application pentest satisfy the requirement?
Ans: Only if its scope actually reached SP-API-connected endpoints and authorization boundaries. Check the exclusions section; see "Does your existing pentest actually cover this?" above.

Q4: What happens after a penetration test finds a vulnerability?
Ans: The organization should remediate each finding according to the deadlines that apply to its data scope. Amazon identifies 7-day Critical and 30-day High remediation deadlines for Solution Providers that store or process PII. After remediation, Amazon requires a second penetration test to confirm that the identified vulnerabilities were completely remediated.

Q5: Does the requirement apply differently when PII is involved?
Ans: Yes. Section 1 applies to all Solution Providers building SP-API applications. Section 2 adds requirements for applications performing restricted operations involving PII, including PII-specific retention and recovery controls and the stated Critical and High vulnerability-remediation deadlines. The 24-hour incident-notification and access-removal requirements remain Section 1 obligations.