Microsoft 365 Certification requires a penetration test. Microsoft’s own Application Security guidance states that penetration testing is a mandatory requirement for all applications undergoing Microsoft 365 Certification, performed at least every 12 months by a reputable independent penetration testing company. The report has to come from manual testing and cannot be scanner output. Where your production environment contains customer-managed infrastructure rather than a fully PaaS setup, the complete internal production network must be in scope. Microsoft also requires evidence approved for 50 percent of in-scope controls before a test can be scheduled. That requirement appears under the Penetration Testing Delivery section, which is written around the test Microsoft arranges through its partner, so confirm with your certification analyst how it applies to a test you commission yourself. Either way it is the sequencing trap most teams hit first.
Everything below comes from Microsoft’s published certification documentation, quoted and linked. Cybersecify runs founder-led penetration testing for AI-first and API-first SaaS startups, and we wrote this because the third-party material on this programme is thin and repeats claims that Microsoft’s documents do not support. Where our own view enters, it is labelled.
Key findings
- Penetration testing is mandatory for all applications undergoing Microsoft 365 Certification, per Microsoft’s Application Security guidance. The stated exception is where the ISV hosts or manages no supporting infrastructure at all.
- The report must be manual. Microsoft’s initial document submission guide states the report “must be produced from manual penetration testing, it can’t be the output of an automated scanning/testing tool.”
- The tester requirement is “a reputable independent penetration testing company” with no accreditation body, no approved-vendor list and no named certification, which is a deliberate contrast with the accredited-auditor gate Microsoft applies to ISO 27001, SOC 2 and PCI DSS evidence on the same programme.
- Evidence for 50 percent of in-scope controls must be approved before the penetration test can be scheduled. The requirement sits under Penetration Testing Delivery, the section that describes the test Microsoft arranges, so confirm with your certification analyst how it applies to an independently commissioned test. That single sentence reorders the whole project plan.
- Responsible AI controls 18 to 27 apply to Copilot and Customer Engine Agent integrations, and two of them require testing at least quarterly: content moderation protections and the user reporting mechanism.
- Certification is annual. If recertification is not completed before expiry, the certification is revoked, the badge is removed, and the ISV may no longer market the app as Microsoft 365 Certified.
Publisher Attestation is not Microsoft 365 Certification
The first thing to get straight, because a lot of published advice conflates them.
| Publisher Attestation | Microsoft 365 Certification | |
|---|---|---|
| What it is | Self-service questionnaire completed in Partner Center about your own security practices | Independent security and privacy audit of the app, add-in or agent and its supporting backend environment |
| Who assesses | Nobody. Your answers are published as-is on a shareable page | Microsoft certification analysts against a defined control set |
| Penetration test | None | Mandatory |
| Output | A published attestation page | The Microsoft 365 Certified badge on the AppSource listing |
| Relationship | Prerequisite for Certification | Requires attestation first, plus publisher verification |
Microsoft’s user guide covers both flows. One detail that catches teams out: if your Publisher Attestation submission is older than three months, you have to resubmit it for review before certification proceeds.
Certification covers Microsoft 365 add-ins for Word, Excel, Outlook, PowerPoint, OneNote and Project, Teams apps, and SharePoint solutions.
Is the penetration test genuinely mandatory?
Yes, and Microsoft says so in one sentence. From the Application Security guidance:
“Penetration testing is a mandatory requirement for all applications undergoing Microsoft 365 Certification. This includes both web application and infrastructure penetration testing.”
The exception is narrow and specific. Microsoft continues that the primary exception applies where the ISV does not host or manage any supporting infrastructure, giving two examples: an application consisting solely of Microsoft 365 components, and a web application hosted entirely within the customer’s own infrastructure with no ISV-managed backend environment. Where the application relies exclusively on Microsoft-managed services, infrastructure testing may not be applicable. In those situations the need for web application testing is assessed case by case, taking into account the application’s architecture, functionality and overall attack surface.
The older framework page words it slightly differently: testing is mandatory for any app that connects to external services not hosted or managed by Microsoft, and apps hosted in Azure must undergo testing. Both pages are live. The Application Security page carries the more recent wording and the broader requirement, so plan against that one.
Practical read: if you run any backend of your own, in Azure or anywhere else, assume the test applies.
Exact scope
Microsoft’s requirement is that testing covers the entire live production environment supporting the app, add-in or agent, including every system, service and piece of infrastructure that hosts, processes, stores or transmits data on the application’s behalf. Four control statements set the boundaries.
| Scope element | What Microsoft requires |
|---|---|
| Web application | Authenticated and unauthenticated testing, covering all relevant vulnerability classes, at minimum those in the current OWASP Top 10 or SANS Top 25 CWE |
| External infrastructure | The complete external attack surface: all public IP addresses, URLs, domains, API endpoints and other internet-facing services, documented in the report |
| Internal infrastructure | Where the production environment contains customer-managed infrastructure, meaning anything other than a fully PaaS environment, the complete internal production network must be included and documented |
| Segmentation | Where segmentation isolates the in-scope environment, the report must validate that the segmentation is effective |
| Environment | Live production, unless an explicit exception applies |
| Connected systems | Any additional environment that interacts with or supports the app, including separate disaster recovery environments |
Two exceptions are written into the guidance and both are worth knowing before you scope.
Infrastructure as Code parity. Where IaC provisions your environments, testing against staging or pre-production may be accepted if you can demonstrate deterministic parity with production through the same IaC templates and CI/CD pipelines. Manual configuration drift or environment-specific security differences between staging and production are not acceptable.
Web application build confirmation. Web application testing should run against live production wherever possible. Testing against UAT or staging is accepted only where production testing is not feasible and the environment is demonstrably representative, and at minimum the report must confirm that the same application build was deployed to production at the time of testing.
If you have never scoped a test before, our guide on how to scope your first pentest covers the mechanics of turning an architecture diagram into a testable scope.
Automatic failure criteria
Microsoft publishes the findings that will normally fail certification until they are remediated and independently retested. Treat this as a pre-test checklist.
- Unsupported operating systems or unsupported JavaScript libraries
- Default, enumerable or easily guessable administrative accounts
- SQL injection
- Cross-site scripting
- Directory traversal, also called path traversal
- HTTP protocol vulnerabilities including HTTP request smuggling, HTTP desync and HTTP response splitting
- Source code disclosure, including local file inclusion
- Any vulnerability assessed as Critical or High under the CVSS-based patch management requirements
- Any significant technical vulnerability that could reasonably be exploited to compromise large volumes of End User Identifiable Information or Organizational User Information
Unsupported JavaScript libraries are the cheapest item on that list to fix in advance and one of the most common to find during a test.
What evidence you have to produce
Microsoft’s initial document submission guide is short and specific on the report itself:
“Include the full penetration testing report with dates evidencing that it has been completed within the last 12 months.
- This report must be produced from manual penetration testing, it can’t be the output of an automated scanning/testing tool.”
That is the clearest statement we have seen from a major platform separating a penetration test from a scan, and it is useful well beyond this programme. If you are weighing a low-cost automated offer against a manual engagement, we wrote about that distinction in manual pentest vs automated scanning and in why scanner output is not a security assessment.
Beyond the report, the controls require:
- Remediation of critical and high risk findings within one month of the completion of testing, or sooner where your own documented vulnerability or patch management process requires it.
- Retest by the same penetration testing company. Every critical and high severity finding, plus anything meeting the automatic failure criteria, must be retested after remediation and clearly identified as resolved in the final report.
- Documented methodology and coverage. The report has to demonstrate the scope of testing, the methodology used, the vulnerabilities identified, and the remediation and retesting activity undertaken.
The retest clause has a procurement consequence people miss. Because the same company must verify the fixes, a vendor who treats retests as a separate quoted engagement, or who cannot commit to a turnaround inside your remediation month, introduces certification risk rather than just extra cost. Ask about retest policy before you sign, not after the report lands. Our own retest terms are on the pricing page, and the report format is on the sample report.
Who is allowed to run the test
This is the question that decides whether you can use your own tester, and Microsoft answers it in the control wording:
“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.”
No accreditation body. No approved-vendor list. No named certification for the tester. The only qualifiers are reputable and independent.
That wording carries more weight once you read it against the neighbouring requirement on the same programme. For the optional external compliance frameworks, Microsoft writes a gate and writes it explicitly: evidence must come from auditors who are “members of international accreditation bodies”, ISO 27001 assessments must be conducted by an accredited external third party with internal audits not accepted, and a PCI DSS attestation must be signed off by a QSA and will not be accepted in self-assessment form. Microsoft knew exactly how to specify an accredited assessor, did so twice on the same page, and did not do it for the penetration test.
Microsoft also offers to arrange the test. From the Penetration Testing Delivery section:
“For ISVs that do not currently undertake penetration testing, Microsoft offers a penetration testing service as part of the Microsoft 365 Certification process through its trusted partner, Claranet.”
Read the condition. It is framed for ISVs that do not currently undertake penetration testing. The framework page says the same thing from the other direction: if the ISV does not currently perform annual penetration testing, the audit team can complete one at an additional cost. Both sentences describe a route for teams that arrive without a test, not a restriction on teams that arrive with one.
Our reading, stated as a reading: the panel is open. An ISV that already runs an annual manual test with a firm it chose is meeting the control as written. An ISV with no test at all has a route sitting inside the process, and should price that route before looking outside it. Both are legitimate and the documentation supports both.
The sequencing trap
This is the section we would put first if the post were ordered by how much money it saves.
“Pre-Test Requirements: ISV must submit evidence and receive approval for 50% of in-scope controls before scheduling the penetration test.”
The penetration test cannot be step one. Evidence collection has to be substantially underway before a test date exists, and the certification clock is running while you do it.
| Stage | Window | What happens |
|---|---|---|
| Initial document submission | 14 days | Architecture and data flow diagrams, system component lists, software asset inventories. Analysts define the assessment scope from these. Roughly 5 percent of the overall process. |
| Full evidence review | 60 days from first evidence submission | Evidence uploaded against all applicable controls, analyst review, revisions, final QA. Penetration testing may be conducted during this window. |
| Extension | Up to 60 further days, at analyst discretion | Valid reasons listed include seasonal holidays, penetration testing delays, internal changes, and time to implement changes needed to meet controls. |
If the ISV cannot complete within the 60 day window the assessment fails, and once both 60 day windows are exhausted no further extension is granted.
Microsoft also publishes a rescheduling and cancellation fee scale for the test it arranges, which tells you a slipped date is not free.
| Request | Timing | Proportion payable |
|---|---|---|
| Reschedule | More than 30 days before start | 0 percent |
| Reschedule | 8 to 30 days before start | 25 percent |
| Reschedule | 2 to 7 days before start, with a firm rebooking date | 50 percent |
| Reschedule | Less than 2 days before start | 100 percent |
| Cancellation | More than 30 days before start | 25 percent |
| Cancellation | 8 to 30 days before start | 50 percent |
| Cancellation | Within 7 days of start | 90 percent |
The planning consequence: book the test against your evidence-approval progress, not against your engineering calendar. Half your in-scope controls have to be approved first, and a date booked optimistically is a date you may pay to move.
Responsible AI controls 18 to 27
This is the part of the programme least covered anywhere else, and it is the reason a Microsoft 365 Certification conversation now lands in the same room as an AI assurance conversation.
Controls 18 to 27 form a Responsible AI domain covering AI technologies integrated into Microsoft 365 apps, add-ins and agents, including Microsoft Copilot and Customer Engine Agents. Microsoft’s stated intent is that ISVs can demonstrate governance, transparency, security, privacy and user protections across the AI lifecycle.
| Control | What it asks for |
|---|---|
| 18 | An inventory of the AI technology in use, whether Microsoft Copilot or a Customer Engine Agent, a list of Copilot Agents and the processes they automate, and a completed Microsoft Responsible AI Impact Assessment |
| 19 | Whether the AI can autonomously perform actions on a user’s behalf, exactly which actions, and the consent process including how consent is obtained, refreshed and withdrawn, with evidence of consent logging |
| 20 | An inventory of every data type the AI processes with personal data called out, every data source it can reach including Microsoft 365 Copilot Connectors, Power Platform Connectors, external connectors, API endpoints and SDKs, and a published privacy notice that reflects the AI functionality |
| 21 | How and when users are notified that AI is in use, and that the notification describes what the AI does |
| 22 | A formal AI policy covering roles and responsibilities, a reporting route for concerns, how bias and fairness are addressed, how AI decisions are made transparent, and how compliance with the policy is monitored |
| 23 | Whether end users can enable or disable the AI, what the default is, and what disabling it costs them in functionality. If no control is permitted, why not, and what alternatives exist |
| 24 | Policies prohibiting inappropriate, harmful or offensive AI-generated content under marketplace certification policy 100.10, reviewed at least every six months, plus testing of the protection mechanisms at least quarterly |
| 25 | A user-facing mechanism to report inappropriate content, acknowledgement of receipt, and testing of the reporting mechanism at least quarterly |
| 26 | Corrective action to the content moderation logic within 2 working days of a substantiated report, testing that the fix worked, and an update back to the reporting user within 2 working days either way |
| 27 | AI functionality described to the customer before acquisition, on first use, when it changes, and at a defined ongoing frequency |
Three things stand out.
The cadence is quarterly, not annual. Controls 24 and 25 both require testing at least quarterly. That is a standing operational commitment sitting inside an annual certification, and it needs an owner and a record before the assessment, not after.
Control 19 is an agent security question wearing compliance clothes. Once an AI integration can act on a user’s behalf, the consent flow, the action boundary and the logging are the security model. That is the same ground covered in our AI agent pentest methodology and the prompt injection attack patterns we see in engagements, and it is why an AI application pentest and an M365 Responsible AI submission end up drawing on the same evidence.
Control 20 is a data inventory problem before it is a security problem. Most teams cannot list every connector, endpoint and SDK the AI can reach without going and looking.
Do SOC 2, ISO 27001 or PCI DSS help?
They can shorten the assessment. They do not remove the penetration test.
Microsoft accepts ISO 27001, SOC 2 Type 2, PCI DSS and FedRAMP evidence as optional supporting material that may satisfy a subset of controls, and states plainly that holding one is not required to obtain Microsoft 365 Certification. The acceptance conditions are strict: the same in-scope environment must be covered, the assessment must be current within the past 12 months, it must be conducted by an independent accredited company, a self-assessment PCI DSS attestation is not accepted, and the SOC 2 must be a Type 2 report. Microsoft also notes that achieving Microsoft 365 Certification does not imply the app has passed audits for those frameworks.
If you are already running a SOC 2 programme, the overlap is real but partial, and the pentest is a separate line item in both. Our post on what SOC 2 auditors actually check in a pentest covers where the two evidence sets meet. Compliance-readiness work sits on our audit and compliance page.
Cadence and what happens if you let it lapse
Certification is annual. Recertification can start up to 90 days before expiry and the existing certification stays valid through that window. If recertification is not completed before the expiry date the certification is revoked: the badge and branding are removed and the ISV may no longer market the app as Microsoft 365 Certified. Significant changes to the app outside the scheduled recertification period must be reported to the Microsoft App Compliance Program.
Budget the penetration test as a recurring annual item tied to the certification anniversary, and start the evidence work early enough that the 50 percent gate is not what delays the test date.
Who this programme is for
Microsoft 365 Certification is aimed at ISVs publishing Microsoft 365 add-ins, Teams apps and SharePoint solutions, and it has become sharply more relevant to AI-first and API-first SaaS startups shipping Copilot integrations and agents, because that is where controls 18 to 27 bite. If your app is a pure Microsoft 365 front end with no backend of your own, your obligation is lighter and may not include infrastructure testing at all. If you run any backend, the full scope applies.
Where we fit, and where to look elsewhere
Being direct about this is more useful than a pitch.
What the requirement allows. Microsoft’s control asks for a reputable independent penetration testing company. There is no accredited panel for the pentest, so an independent firm you choose is accepted by the wording. Cybersecify does founder-led manual testing of web applications and APIs, external infrastructure, cloud environments and internal production networks, and both founders run every engagement personally. Because M365 scope is driven by whether your environment is fully PaaS, the internal leg is decided during scoping rather than picked off a plan, so start at contact with your architecture rather than at a price. Published plan pricing is on the pricing page.
Where to look first if you have no test at all. Microsoft offers a penetration testing service inside the certification process through its trusted partner Claranet, and the framework page separately notes the audit team can complete one at an additional cost. If you are starting from zero, price that route before you price anyone else. It sits inside the process, the certification analysts already have context on your scope, and a route arranged by the programme has fewer coordination seams than one arranged around it. We would rather tell you that than have you find it later.
Where an independent firm earns its place. Three situations, in our experience. First, you already run an annual manual pentest for SOC 2, an enterprise customer or an investor, and you want one engagement that serves all of them rather than a separate M365-only test. Second, you want to talk to the person who tested your application, about your architecture, before and after the report. Third, you want the remediation and retest cycle to fit your release calendar rather than a queue.
What we do not do. We are not the certification analyst and we do not decide the outcome. The assessment, the control approvals and the certification decision are Microsoft’s, and no pentest vendor can promise a pass. Anyone who does is selling you something they do not control.
One thing worth doing regardless. Read Microsoft’s automatic failure list and the Responsible AI cadence in controls 24 to 26 before you book anything. Both are cheaper to satisfy in advance than to discover mid-assessment.
If you are weighing what a manual engagement costs and what it should include, pentest cost in India and how to evaluate a penetration testing firm cover the questions worth asking any vendor, including us.
Corrections
- 2026-08-09: Expanded three bare “seg2_app” source attributions to the full Microsoft Learn URL, and corrected one that attributed the 14 day, 60 day and fee-scale figures to seg2_app when they appear on the Microsoft 365 Certification framework page.
- 2026-08-09: Hedged the 50 percent control-approval gate. The requirement appears under Penetration Testing Delivery, the section describing the test Microsoft arranges through its partner, so readers are now told to confirm with their certification analyst how it applies to an independently commissioned test.