Microsoft 365 Certification Penetration Testing
Certification is blocked until an independent penetration test covers your live production environment, and the report has to answer sixteen controls one by one. You are either starting certification, renewing the annual test, or sitting on a submission that came back for evidence. The scope, the published price and the timeline are on this page, before you talk to us.
Four things about this certification that get buyers oversold
Publisher Attestation is not this. It is the prerequisite step, a self-assessment questionnaire in Partner Center, and it carries no penetration testing requirement at all. If someone quoted you a pentest to complete Attestation, they quoted you the wrong thing.
Microsoft set no accreditation bar for the tester. The control says a reputable independent penetration testing company. On the same page Microsoft requires ISO 27001, SOC 2 and PCI DSS evidence to come from accredited auditors, and a PCI DSS attestation to be signed by a QSA. It wrote that requirement twice and did not write one here.
Nobody can promise you a pass. Controls 7 to 15 are automatic failure criteria and each is phrased as an absence. Whether your report can evidence those absences depends on your application and on what your engineers fix. A vendor promising a clean result is telling you they will either not look hard or not write down what they find.
You may not be able to book the test yet. Microsoft states that an ISV "must submit evidence and receive approval for 50% of in-scope controls before scheduling the penetration test". That sits in the delivery section written around the test Microsoft arranges through its own partner, so confirm with your certification analyst how it applies to a test you commission yourself. Either way it is the sequencing step most teams meet first, and it decides when testing can actually start.
The retest is part of the requirement, not an upsell. Control 16 requires the company that found the issue to verify the fix, inside the final report. A retest sold as a separate engagement, or delivered as a note appended to the original document, is weaker evidence than a reissued report.
What our reports have had to satisfy elsewhere
Microsoft's controls ask for a report that a reviewer can work through line by line: scope documented, findings evidenced, remediation verified. That is the same structure we already produce: every finding carries a CVSS score with its full vector string, a CWE identifier, reproduction steps, evidence, business impact and a specific remediation, and the retest reissues the report with the fixed state evidenced rather than asserted.
The point is narrower and more useful to you than a claim about other frameworks: the report is built to be checked line by line, which is the only property that matters when a reviewer has the authority to reject it.
What Microsoft puts in scope, and what we test against each
Web application, authenticated and unauthenticated
Both surfaces, as the control requires. Authentication and session handling, authorisation across every role you expose, business logic, and the injection and traversal classes that sit inside the automatic failure list.
The complete external attack surface
All public IP addresses, URLs, domains, API endpoints and other internet-facing services, enumerated and documented in the report because the control requires the report to document them.
The internal production network
In scope wherever the environment is not fully PaaS, meaning you manage infrastructure. Where segmentation isolates the in-scope environment, the report validates that the segmentation actually holds rather than asserting it.
Every production component that could affect the in-scope environment
Microsoft requires testing to cover the entire live production environment, including any additional production environments, systems or services that interact with or support the application. Scope is agreed against that wording rather than against a list of environment names.
Microsoft's penetration testing controls, and what we test or produce for each
Microsoft's own sample evidence guide states it in one line: Controls 1 to 16 relate to penetration testing. All sixteen are testing controls. Six govern how the test is run and who runs it, nine name findings that fail the certification until they are remediated and independently retested, and the sixteenth closes on the retest. In Partner Center you submit evidence control by control, so this is the order your reviewer reads in.
Read the right-hand column for Controls 7 to 15 carefully. Each of those nine is written by Microsoft as an absence, so what we commit to is testing for every one of them and writing down what is actually there. What comes back clean is a property of your codebase and your remediation work, not of who tested it.
| Control | What Microsoft requires | What we test or produce for it |
|---|---|---|
| 1 | Testing performed within the past 12 months. | The report is dated and carries the testing dates, so the window is visible to the reviewer rather than asserted. Certification runs on an annual recertification cycle, so this is a recurring annual line item tied to your certification anniversary. |
| 2 | The tester and the testing company are suitably qualified. Microsoft’s published wording is a reputable independent penetration testing company. | The report names the people who performed the testing and records what they hold, and it is issued by a firm with no stake in the systems it tested. A report signed only by a company logo gives a certification analyst nothing to assess. |
| 3 | Web application testing, authenticated and unauthenticated. | Both surfaces, across every role your application actually has rather than a single logged-in user. Authentication, session handling, authorisation between roles, and business logic. |
| 4 | Web application and infrastructure testing: the external footprint, and the internal network where applicable. | The complete external attack surface enumerated and documented in the report. The internal production network as its own scope unless the environment is fully PaaS. Where segmentation isolates the in-scope environment, the report validates that the segmentation holds rather than asserting it. |
| 5 | Industry-recognised vulnerability classes are tested for, at minimum the current OWASP Top 10 or SANS Top 25 CWE, with the methodology written down. | The methodology names the standards the coverage was built against: PTES for the engagement lifecycle, NIST SP 800-115 for assessment structure and evidence handling, and OWASP WSTG v4.2, ASVS 5.0.0 and Top 10:2025 for web coverage. Every finding carries a CWE identifier plus the OWASP category matched to the surface tested. Microsoft requires manual testing, so scanner output is not the deliverable at any point. |
| 6 | A WAF or IDPS did not interfere with the test. | Settled in the SOW before testing starts: either an allowlisted testing position, or the presence and behaviour of the protective layer documented in the report so a reviewer can tell which findings were reached and which were blocked. This is the control buyers miss most often, because a blocked test produces a clean-looking report over an unchanged application. |
| 7 | Unsupported operating systems or unsupported JavaScript libraries. | The serving stack and the JavaScript your application actually serves are checked against supported versions, with the version to move to named per finding. This is the cheapest of the nine to clear before anyone starts testing: run a dependency inventory this week. |
| 8 | Default, enumerable, or easily guessable administrative accounts. | Administrative authentication tested for default credentials, account enumeration and guessable values, across every administrative role you expose rather than the one you demo. |
| 9 | SQL injection vulnerabilities. | Manual injection testing across the parameters and data paths reachable from each tested surface, authenticated and unauthenticated, with a working reproduction per finding. |
| 10 | Cross-site scripting vulnerabilities. | Reflected, stored and DOM-based cases, each with the exact request and context that produced it rather than a scanner signature. |
| 11 | Directory traversal, also called path traversal, vulnerabilities. | File handling and path handling endpoints tested for traversal, with reproduction steps a developer can follow to confirm the fix themselves. |
| 12 | HTTP protocol vulnerabilities, including HTTP request smuggling, HTTP desync and HTTP response splitting. | Tested across the request chain rather than at one hop, because this class lives in the disagreement between an edge component and the origin behind it. |
| 13 | Source code disclosure vulnerabilities, including local file inclusion. | Tested for, and anything disclosed is reported with the exact request that produced it and what it exposed, so the severity can be checked rather than taken on trust. |
| 14 | Any vulnerability assessed as Critical or High in accordance with the CVSS-based patch management requirements. | Every finding carries a CVSS score with the full vector string, so the band can be recomputed rather than believed. Critical and High are not adjectives in this control; a severity that cannot be recomputed cannot be checked by your engineers or by a certification analyst. |
| 15 | Any significant technical vulnerability that could reasonably be exploited to compromise large volumes of End User Identifiable Information or Organizational User Information. | Authorisation and tenant isolation tested on the paths that return data in volume, with the business impact stated per finding rather than left to the reviewer to infer from a severity band. |
| 16 | All Critical and High severity findings, and anything constituting an automatic failure, retested by the penetration testing company following remediation and clearly identified as resolved within the final report. | Included in both plans, not a separate engagement, because this control requires the firm that found the issue to verify the fix. The retest produces a v2.0 report that supersedes v1.0, with updated status on every original finding plus fresh evidence of the fixed state. Microsoft’s own remediation window runs one month from the completion of testing, which starts before v1.0 is issued, so on a certification engagement we sequence the retest to Microsoft’s date rather than ours. In practice that means we agree the retest window in the SOW before testing starts, working backwards from your submission date rather than forwards from our report, and we tell you at kickoff what date your fixes have to be in by for the retest to land inside Microsoft’s window. What we cannot do is control how long Microsoft takes once you submit, and no vendor can. |
Microsoft's requirements above are quoted and paraphrased from its Application Security sample evidence guide and its certification framework page, both read on 21 August 2026. The full control-by-control reading, including the wording of each automatic failure criterion and the six questions worth asking any vendor about them, is in Controls 1 to 16. The programme mechanics around them, including Publisher Attestation, the 50 percent evidence gate and the Responsible AI controls, are in the requirements guide. Control 2 and Control 14 are checkable before you contact anyone: open our sample report and look for named assessors and a full CVSS vector on every finding. Control 4 decides whether your engagement includes an internal network scope alongside the web application work, and our engagement process sets out the sequence either way.
What a certification engagement costs
The plan is the Compliance Plan, which covers two scopes at INR 1,79,999, with each additional scope at INR 74,999. A certification engagement is normally two or three scopes: the web application, the external attack surface, and the internal production network where you manage infrastructure. A fully PaaS environment often comes to two.
| Two scopes, a fully PaaS environment with no internal leg | INR 1,79,999 · 12 business days |
| Three scopes, where Control 4 pulls the internal production network in | INR 2,54,998 |
Prices exclude taxes. A scope is six business days, five testing and one writing the report, so the report lands inside the window rather than after it. For larger estates we confirm the schedule when we scope it. The retest is included in the plan and is not a separate line, which is what Control 16 needs. Full terms are on our pricing page.
What you receive
- A penetration test report covering the entire live production environment supporting the app, written to be submitted as Partner Center evidence control by control.
- Every finding with a CVSS v3.1 and v4.0 score and full vector string, a CWE identifier, reproduction steps, evidence, business impact and specific remediation.
- The external attack surface documented in the report, as the control requires, not summarised.
- Segmentation validation where segmentation is used to isolate the in-scope environment.
- A v2.0 report after the retest, superseding v1.0, carrying updated status on every original finding plus fresh evidence of the fixed state.
- A Letter of Attestation signed by the lead tester after the retest, on the Compliance Plan.
Microsoft 365 Certification pentest questions
Does Microsoft 365 Certification require a penetration test?
Yes. Microsoft’s Application Security guidance states that penetration testing is a mandatory requirement for all applications undergoing Microsoft 365 Certification, covering both web application and infrastructure testing, at least annually. The stated exception is where you host or manage no supporting infrastructure, for example an app built solely from Microsoft 365 components or hosted entirely inside the customer’s own infrastructure with no backend you manage. Note that Publisher Attestation, the prerequisite step, is a self-assessment questionnaire and carries no pentest requirement at all.
Who is allowed to perform the test?
Microsoft’s wording is a reputable independent penetration testing company. It names no accreditation body, no approved-vendor list and no certification for the tester. That is worth reading against the neighbouring requirement on the same page, where Microsoft does impose gates: ISO 27001, SOC 2 and PCI DSS evidence must come from auditors who are members of international accreditation bodies, and a PCI DSS attestation must be signed off by a QSA. Microsoft wrote an accreditation requirement twice on that page and did not write one here.
What must be in scope?
The entire live production environment that supports the app, add-in or agent, including all systems, services and infrastructure that host, process, store or transmit data on its behalf. Web application testing covers authenticated and unauthenticated surfaces. The complete external attack surface must be in scope and documented in the report. Where the environment is not fully PaaS, the complete internal production network is in scope. Where segmentation isolates the in-scope environment, the report must validate it. Scope extends to any additional production environments, systems or services that interact with or support the application.
Can you guarantee we pass Controls 7 to 15?
No, and a vendor who says otherwise has promised something no tester can deliver. Controls 7 to 15 are Microsoft’s automatic failure criteria and each is phrased as an absence: no unsupported operating system or JavaScript library, no default or guessable administrative accounts, no SQL injection, no cross-site scripting, no directory traversal, no HTTP protocol issues, no source code disclosure, nothing rated Critical or High under the patch management requirements, and no significant vulnerability that could reasonably be exploited to compromise large volumes of customer data. Whether your report can evidence those absences depends on what is in your application and what your engineers fix. Our job is to test for every one of them, write down what is actually there, and retest once you have fixed it so the report can show the fixed state. Not being able to promise the outcome is not the same as not being able to help you reach it.
How does the retest satisfy Control 16?
Control 16 requires that all Critical and High severity vulnerabilities, and anything constituting an automatic failure, are retested by the penetration testing company following remediation and clearly identified as resolved within the final report. Two phrases decide what to ask a vendor for. By the penetration testing company means the firm that found it verifies the fix, so a retest quoted as a separate engagement is a certification risk rather than a line item. Within the final report means the evidence lives in the document the reviewer reads. Our retest produces a v2.0 report that supersedes v1.0 and is included in both plans: one month from v1.0 is the outer bound, not a wait, and we go sooner once your fixes land. Note the two clocks differ. Microsoft’s own remediation window runs one month from the completion of testing, which starts before v1.0 is issued, so on a certification engagement we sequence the retest to Microsoft’s date rather than ours. In practice that means we agree the retest window in the SOW before testing starts, working backwards from your submission date rather than forwards from our report, and we tell you at kickoff what date your fixes have to be in by for the retest to land inside Microsoft’s window. What we cannot do is control how long Microsoft takes once you submit, and no vendor can.
What does a Microsoft 365 Certification pentest cost?
Our published price. The plan is the Compliance Plan at INR 1,79,999, which covers two scopes, and each additional scope is INR 74,999. A typical certification engagement is two or three scopes: the web application, the external attack surface, and the internal production network where you manage infrastructure. A fully PaaS environment often comes to two. Three scopes is INR 2,54,998. Prices exclude taxes.
Can you test a staging environment instead of production?
Sometimes, and Microsoft sets the terms. Where Infrastructure as Code provisions your environments, testing a staging environment may be accepted if you can demonstrate deterministic parity with production through the same IaC templates and CI/CD pipelines. Where production web application testing is not feasible, the report must at minimum confirm that the same application build was deployed to production at the time of testing. We will tell you which of those your estate actually supports before you commit.
Send us your architecture, not a plan choice
Tell us what you host and manage, what is PaaS, which other production systems touch the application, and the date the submission has to be in. That is what decides the scope count, and the scope count is what decides the price. Both co-founders are on the call. Certification itself is Microsoft's decision through its own assessor, and we will never tell you otherwise. What we can do is the part that falls to us: deliver the testing and the report its controls ask for, so the evidence side is covered and what is left is theirs to decide.
Where these requirements come from
Everything this page says about the platform's requirements is taken from the platform's own published documentation, linked below and last checked on 2026-10-03. We quote the requirement rather than our reading of it wherever the difference matters.
- Microsoft 365 Certification: Application Security sample evidence guide (Controls 1 to 16)
- Microsoft 365 Certification: certification overview
Our aim is to describe these requirements as accurately and as currently as we can, and to show you where to check us. We are reading someone else's documentation: a platform can revise it without an announcement, and our reading of it can be imprecise or go out of date.
How we source, draft and review what we publish, including where software sits in the drafting, is set out in our editorial policy. A page like this is only as good as the date on it, so we re-read the sources on a standing audit, date what we checked, and update the page when a source moves or when we can state something more precisely.
If something here no longer matches the source, tell us at errors@cybersecify.com. We will review it against the source and tell you what we decide; where it needs changing we change it and date the change.
This page is published for information. It is a best-effort account of someone else's published requirements, not a commitment about your engagement: what we deliver, and what it costs, is set out in the Statement of Work both parties sign, and our terms state that where website content and a signed agreement differ, the signed agreement governs.