Microsoft 365 Certification puts sixteen numbered controls on the penetration test. Microsoft’s own sample evidence guide states it plainly: “Controls 1-16 relate to penetration testing.” Every one of the sixteen is a testing control. There is no policy item and no legal item hiding in the block. Six of them govern how the test is run and who runs it, nine name findings that fail the certification until they are fixed, and the sixteenth closes on a retest. Microsoft grants the certification. Your tester produces the report the reviewer reads. No tester can promise the outcome.
Say the obvious part first
Microsoft grants Microsoft 365 Certification. A penetration testing firm does not, and cannot. What a firm produces is the report your certification analyst reads, and the retest evidence that closes the findings. That is a real and specific job, and it is worth choosing carefully. It is not the certification.
We are writing this down at the top rather than in a disclaimer at the bottom because the distinction is the most useful thing on this page. If a vendor promises to deliver the certification itself, they have described an outcome they do not control. The reasonable version of that sentence is: we will test your application and infrastructure against the sixteen controls, report what is actually there, and retest what you fix.
This post covers the sixteen controls and how to evaluate a vendor against them. For the mechanics of the programme itself, the difference between Publisher Attestation and Certification, the 50 percent evidence gate before a test can be scheduled, the assessment timeline and the Responsible AI controls 18 to 27, see our earlier post on Microsoft 365 Certification pentest requirements. We have not repeated that ground here.
Where the sixteen controls actually live
Two Microsoft surfaces carry this material and they are shaped differently. Knowing which is which saves an argument with a vendor later.
Partner Center is where an ISV submits evidence control by control, and it is where the controls appear as a numbered list of sixteen. That surface sits behind a login, so we are not linking it. The list below is the one an ISV sees in the submission flow.
Microsoft Learn publishes the same requirements without the numbering, in two blocks. The Application Security sample evidence guide opens the penetration testing section with the sentence “Controls 1-16 relate to penetration testing”, then sets out a penetration test controls table and an automatic failure criteria list. The Microsoft 365 Certification framework page carries an older, near-identical version of the same two blocks. Both pages were accessed on 21 August 2026.
One detail worth knowing if you are reading the source yourself: the sample evidence guide currently lists the OWASP Top 10 and SANS Top 25 coverage requirement twice, in two slightly different wordings, one after the other. It is the same requirement stated twice, not two requirements.
Controls 1 to 6: how the test is run, and by whom
These six decide whether the test itself is acceptable before anyone looks at what it found.
| Control | What it asks | What the report has to show |
|---|---|---|
| 1 | Testing performed within the past 12 months | The report is dated, and the testing dates sit inside the window at the time of submission |
| 2 | The tester and the testing company are suitably qualified | Microsoft’s published wording is “a reputable independent penetration testing company”. The report is where that is evidenced |
| 3 | Web application testing, authenticated and unauthenticated | Both, across every role your application actually has, not just a single logged-in user |
| 4 | Web application and infrastructure testing, external footprint and internal network where applicable | The complete external attack surface documented. The internal production network too, unless the environment is fully PaaS |
| 5 | Industry-recognised vulnerability classes are tested for | Coverage against at minimum the current OWASP Top 10 or SANS Top 25 CWE, with the methodology written down |
| 6 | A WAF or IDPS did not interfere with the test | The presence and behaviour of any protective layer recorded, or the tester positioned so it does not sit in the path |
Microsoft’s published control statement behind rows 1 to 4 reads:
“Web application (authenticated and unauthenticated) and both external infrastructure and internal infrastructure (where applicable) penetration testing MUST be performed at least annually (every 12 months) by a reputable independent penetration testing company.”
On Control 2, note what is not there. Microsoft names no accreditation body, no approved-vendor list and no specific certification for the tester. That is a deliberate contrast with the same programme’s treatment of external framework evidence, where Microsoft does write an accreditation gate for ISO 27001, SOC 2 and PCI DSS auditors. Because the wording is open, the report is the only place a reviewer can form a view. A report that names the people who did the testing and records what they hold gives the analyst something to assess. A report signed only by a company gives them nothing.
On Control 4, the split is architectural rather than commercial:
“Where the production environment contains customer-managed infrastructure (i.e. other than a fully PaaS environment), the complete internal production network MUST be included within the penetration testing scope and clearly documented within the penetration testing report.”
So a pure PaaS estate may carry no internal leg. Any virtual machine, container host or self-managed data store you administer yourself pulls the internal network into scope alongside the web application work. Settle this from your architecture diagram before you take a quote, because it is the largest single driver of what the engagement costs.
Control 6 is the one most buyers have never considered, and it is the one we would ask about first. A web application firewall or an intrusion detection and prevention system sitting in front of your application can block the tester’s traffic and produce a report that looks clean because the test never reached the application. The vulnerability is still there. The protection hid it from your tester, and it will not hide it from an attacker who takes the time to work around it. This is a test validity control. The programme is guarding against a falsely clean report, not against your having a WAF.
The scoping consequence is small but it has to be agreed up front: testing usually needs either an allowlisted position or the WAF’s presence and behaviour documented, so the report can evidence Control 6 either way. Put it in the statement of work.
Controls 7 to 15: the nine findings that fail you
These nine are Microsoft’s automatic failure criteria. Quoted from the Application Security sample evidence guide, accessed 21 August 2026, the presence of any of the following “will normally result in an automatic certification failure until the vulnerability has been remediated and independently retested”:
| Control | Microsoft’s wording |
|---|---|
| 7 | ”Unsupported operating systems or unsupported JavaScript libraries.” |
| 8 | ”Default, enumerable, or easily guessable administrative accounts.” |
| 9 | ”SQL Injection vulnerabilities.” |
| 10 | ”Cross-Site Scripting (XSS) vulnerabilities.” |
| 11 | ”Directory Traversal (Path Traversal) vulnerabilities.” |
| 12 | ”HTTP protocol vulnerabilities, including HTTP Request Smuggling, HTTP Desync, and HTTP Response Splitting.” |
| 13 | ”Source code disclosure vulnerabilities, including Local File Inclusion (LFI).“ |
| 14 | ”Any vulnerability assessed as Critical or High in accordance with the CVSS-based patch management requirements.” |
| 15 | ”Any significant technical vulnerability that could reasonably be exploited to compromise large volumes of End User Identifiable Information (EUII) or Organizational User Information (OUI).” |
The honest distinction, and it is the spine of this page
Read the phrasing again. Every one of those nine is stated as an absence. Confirm that no SQL injection was present. Confirm that no unsupported library was present. Confirm nothing scored Critical or High.
That is a criterion the report has to evidence, and whether it can depends on what your engineers fix. No penetration tester controls it. A tester controls whether the testing was thorough and whether the findings were written down accurately. What comes back clean is a property of your codebase and your remediation work.
So the honest shape of the engagement is this. We test for every one of the nine and report what is actually there. Your team remediates. Control 16 closes at the retest. A vendor who tells you Controls 7 to 15 will come back clean has promised something no tester can deliver, and there are only two ways to produce that result: do not look hard, or do not write down what you found. Both leave you worse off in front of a reviewer than an honest report with findings in it, because findings plus verified fixes is a normal certification path and Microsoft’s own control set is built around it.
Control 14 is worth a separate word because it is where vague reporting does real damage. “Critical” and “High” are not adjectives here. They are CVSS bands, and the assessment has to be defensible. A report that asserts a severity without publishing the vector it was derived from cannot be checked by you, by your engineers or by a certification analyst. A report that publishes the full vector can be recomputed against the FIRST CVSS calculator by anyone who doubts it. That difference decides whether Control 14 is evidenced or merely asserted.
Control 7 is the cheapest one to clear in advance. Unsupported JavaScript libraries turn up constantly and a dependency inventory usually finds them in an afternoon. Fixing them before a test costs a sprint. Discovering them during one costs a retest cycle and a slipped submission date.
Control 16: the retest is the control
Microsoft’s wording:
“All Critical and High severity vulnerabilities, together with any vulnerability that constitutes an automatic failure, MUST be retested by the penetration testing company following remediation and clearly identified as resolved within the final penetration testing report.”
Two phrases in that sentence decide what you should be buying.
“By the penetration testing company.” The firm that found the issue has to verify the fix. A retest quoted as a separate engagement, or one that cannot be scheduled inside your remediation month, is a certification risk rather than a cost line. Microsoft’s remediation control gives you one month from the completion of testing for Critical and High findings, so the retest has to fit inside that.
“Within the final penetration testing report.” The evidence has to live in the document the reviewer reads. A one-line note appended to the original report is thinner evidence than a reissued document that carries the original finding, what was changed, how it was re-checked, and what the re-check observed.
Our own retest produces a v2.0 report that supersedes v1.0, with updated status on every original finding plus fresh evidence of the fixed state, included in both pentest plans within one month of the v1.0 report. The retest itself runs 1 to 3 business days. You can read the format in the sample report rather than take our description of it.
One report, and what a Microsoft 365 engagement adds to it
A fair question at this point is whether the report changes depending on what you pay. Here is the whole answer, because a vendor who is vague about it is usually protecting a thin document at the bottom of their range.
We write one report to one findings schema. Every finding, on every engagement, at every plan tier, carries the same fields:
- The finding ID, its title, the scope it belongs to and the affected endpoint
- A severity band, and a CVSS v3.1 score with the full vector string, so the rating can be recomputed rather than believed
- A CWE identifier, and a second one where the weakness genuinely spans two classes
- The OWASP category matched to the type of surface tested
- A description, reproduction steps, evidence, business impact and a specific remediation
- On every remediated finding, a retest block: what was applied, how it was re-checked, what was observed, the result, and fresh evidence of the fixed state
At the document level, every report carries an executive summary, the scope and methodology, a findings summary, a severity distribution, an appendix and a disclaimer, and names the lead assessor with their credential.
None of that is held back by tier. A Startup plan buyer receives the identical core report. There is no cut-down edition, no summary version, and no finding detail we print for one buyer and withhold from another. We would rather say it plainly than let you assume the cheaper plan buys a thinner document, because it does not. What the plans differ on is how many scopes are tested, how many consulting hours come with the engagement, and the compliance layer below.
The compliance layer sits on the Growth plan. Three things: a per-finding mapping to SOC 2 Trust Services Criteria and ISO 27001:2022 Annex A controls, a compliance evidence package that turns those mappings around into control-to-findings matrices, and a Letter of Attestation issued as a separate document after the retest, so it describes the remediated state rather than the original findings.
For an engagement scoped to this programme, a Microsoft 365 appendix. It indexes the same findings against Controls 1 to 16, so your certification analyst can read the report in the order Partner Center asks the questions instead of reconstructing the mapping themselves. Same findings, a second index over them.
Hold one thing in mind while reading those last two paragraphs. A mapping changes how findings are presented. It does not change what was tested. Nobody tests harder because a compliance appendix is attached, and nobody tests less thoroughly because one is not. It also carries no weight with a certification analyst beyond the findings underneath it, and it cannot close Controls 7 to 15 on your behalf, since those close when your engineers fix what the test found. If you are doing Microsoft 365 Certification, the appendix saves your team and your reviewer the reconciliation work. If you are not, you would never have opened it, and you should not be paying for it.
Three controls you can verify before contacting anyone
Most of what a security vendor tells you cannot be checked until you are a customer. Three of these sixteen can, because the evidence for them is visible in a published report.
Control 2, tester qualifications. Open our sample report and look at the cover page and the appendix. The lead assessors are named there and their credentials are listed. Engagement reports record the lead assessor’s certification number alongside the name. Do the same check on any vendor’s sample. If you cannot find a human being in the document, the reviewer will not find one either.
Control 14, no Critical or High by CVSS. Every finding in that report carries a CVSS score with the full vector string, so the score can be recomputed rather than believed. Check whether the sample you are given does the same, or whether severity is an unexplained word.
Control 16, remediation verified. The sample report includes the retest section: each original finding with what was applied, how it was re-checked, what was observed, and the result. That is what “clearly identified as resolved within the final report” looks like in practice.
We publish that report in full, with no form in front of it, precisely so these three are checkable before a conversation starts.
What to check with any vendor
This section is useful whether or not you hire us. Take it into any conversation, including ours.
1. Does the report name a specific test-case identifier per finding, or just a framework name? “Tested against OWASP” is a claim. A finding that names the test case it came from is evidence. A reviewer reconciling your report against Control 5 needs to see coverage, not a logo. Since this is a bar and we are asking you to hold vendors to it, here is where we stand on it: our reports name the standards the coverage was built against in the methodology section, and every finding carries a CWE and an OWASP category, but the published sample does not print a per-test-case identifier on each finding. Ask us the same question you ask anyone else.
2. Is severity a CVSS vector you can recompute, or an adjective? Ask to see a sample finding. If it says High and stops, you cannot check it and neither can the analyst assessing Control 14. If it carries the vector, you can put it into a calculator yourself.
3. Is a retest included, and is it a full updated report or a one-line note? Ask three things: is it in the price, what is the turnaround, and what document do I receive. Control 16 needs the resolution evidenced in the final report, and your remediation window is one month.
4. Who signs it, and are they named with a credential you can verify? Control 2 is evidenced in the document or not at all. Ask whether the individuals who did the testing are named in the report itself.
5. Did the tester confirm a WAF or IDPS was not masking results, and does the report say so? This is Control 6 and it is the one most buyers miss. A WAF can block the tester and produce a report that looks clean because the test never reached the application. The vulnerability is still there. Ask for the confirmation in writing, in the report, before you accept a clean result.
6. Does the vendor claim they can get you approved? Nobody can. Microsoft’s certification analysts decide, against Microsoft’s control set. Any vendor offering a guaranteed pass, an approval rate or a success rate is either misunderstanding the programme or hoping you do. There is no pass-rate figure any penetration testing firm can honestly quote you, including us.
Two more that are not on the certification checklist but decide how the engagement actually goes. Ask whether you can speak to the person who tested your application, before and after the report. And ask what happens if testing runs long, because the certification clock does not pause. Our longer guide on how to evaluate a penetration testing firm covers the general version of these questions, and how to read a VAPT report covers what a good one looks like once it lands.
Where we fit
Cybersecify is founder-led penetration testing for AI-first and API-first SaaS startups. Both founders are hands-on in every engagement. For a Microsoft 365 Certification submission that means a manual web application test covering authenticated and unauthenticated surfaces across your real role structure, external attack surface coverage, internal network testing where your environment is not fully PaaS, findings scored under CVSS with the vector published, and a v2.0 retest report that evidences what was fixed. Compliance-readiness work sits on our audit and compliance page, and plan pricing is on the pricing page.
What we do not do. We are not the certification analyst. We do not decide the outcome, we cannot promise one, and we have no pass-rate to quote because no honest tester has one. We also do not perform or sign SOC 2 examinations; a CPA partner does that and we refer.
Where to start. Because Control 4 is decided by your architecture rather than by a plan tier, the useful first message is your architecture diagram and your submission deadline, not a request for a price. Start at contact.
One thing worth doing regardless of who tests you. Run a dependency inventory against Control 7 this week. Unsupported JavaScript libraries are the most common automatic failure we would expect to meet and the cheapest to clear before anyone starts testing.
Sources
- Microsoft, Microsoft 365 Certification sample evidence guide: application security. Accessed 21 August 2026. Source of the “Controls 1-16 relate to penetration testing” statement, the penetration test controls table, and the automatic failure criteria quoted above.
- Microsoft, Microsoft 365 Certification framework overview. Accessed 21 August 2026. Source of the general criteria table and the earlier wording of the automatic failure criteria.
- Microsoft, Initial document submission guide. Accessed 21 August 2026. Source of the requirement that the report be produced from manual testing rather than automated scanning output.
- The numbering of the sixteen controls is taken from the control set an ISV sees in Microsoft Partner Center during evidence submission. That surface is behind a login and cannot be linked. Where a control’s wording is quoted above, the quotation is from the Microsoft Learn pages listed here.
- OWASP Top 10 and the FIRST CVSS v3.1 calculator, referenced for Controls 5 and 14.
Microsoft’s certification documentation changes. Every requirement above was read from the pages listed on 21 August 2026, and the sample evidence guide had itself been updated on 31 July 2026. Check the live pages against your own submission date rather than trusting any third-party summary, including this one.