Microsoft 365 App Certification submission guide

Introduction

Microsoft 365 App Certification offers assurance and confidence to enterprise organizations that data and privacy are adequately secured and protected when your Microsoft Word, Excel, PowerPoint, Outlook, Teams integration, or Graph API apps are introduced to the Microsoft 365 platform. Applications that pass validation will be designated Microsoft 365 App Certified throughout the Microsoft 365 ecosystem.

Important

Currently, Microsoft 365 App Certification is limited to Microsoft Teams apps.

Prerequisites

Publisher Attestation

Before starting the Microsoft 365 App Certification process, you'll need to have successfully completed your Publisher Attestation submission. Following your request for certification, you'll be presented with your completed attestation documentation. If necessary, edit and update your responses; however, if you do so, you'll need to resubmit your attestation documentation for approval.

External Compliance

If you are currently in compliance with other security frameworks, they will be considered when assessing the controls within the Microsoft 365 App Certification Specification. Currently, the security frameworks that count towards Microsoft 365 certification are:

  • PCI DSS.

  • SOC 2.

  • ISMS / IEC - IS0/IEC 27001 specification.

    For due diligence, the certification analysts will sample a set of controls that are found to be in place through other security frameworks.

Certification Program updates

Updates to this program are anticipated approximately every three to six months. These updates might introduce new target security domains and / or security controls. Updates will be based on developer feedback, changes to the threat landscape, and to increase the security baseline of the program as it matures. Additionally, these updates will aim to increase the certification passing thresholds.

Certification Scope

The term in-scope system components references the infrastructure supporting the application and the application itself and will be the primary focus of the assessment process. In-scope components include, but aren't limited to:

  • The web application(s).
  • Servers.
  • Firewalls (or equivalent).
  • Switches.
  • Load balancers.
  • Virtual infrastructure.

Important

The in-scope environment, must have a DMZ and the internal supporting infrastructure of the application must be isolated from the internal business systems and corporate networks thus limiting the scope of the assessment activities to the in-scope systems supporting the application.

Tip

If your app is available to multiple Microsoft 365 applications and the in-scope system components are the same for each, consider including all of the in-scope system components and endpoints as part of your assessment.

Sampling

Requests for evidence in support of the certification assessment should be based on a sample of the in-scope system components in consideration of different operating systems, primary function, and different device types.

Platform as a Service (PaaS) and Software as a Service (SaaS)

Where PaaS and SaaS are used to support the application under review, the Cloud platform provider will be responsible for much of the security controls assessed throughout the certification process. Therefore, certification analysts will need to be provided with independent external verification of security best practices by the Cloud platform provider through external compliance reports such as PCI DSS Attestation of Compliance (AOC) or SOC 2 Type II reports.

Certification Process

Before starting the certification process, you would need to have successfully completed your Publisher Attestation. Your attestation responses of which will be used in support of the app certification process and proceeds as follows:

 ✓ Complete the Publisher Attestation.
 ✓ Request Microsoft 365 App Certification with Microsoft.
 ✓ Submit a series of documentation in support of the audit process, detailed within the Initial Document Submission, below.
 ✓ Provide additional evidence in support of the Microsoft 365 App Certification application.
 ✓ Provide a signed statement attesting to the validity of evidence submitted and your pledge to maintain governance, risk management, assurance and compliance regimes in place, and/or notify Microsoft of any significant changes.

Important

Ideal submission time frame (30 days):
Developers must ensure that this certification submission guide has been read and that all controls can be met before starting the certification process. Upon starting the certification process, a 30-day time limit starts. The assessment should be completed within this 30-day period.

Extension (30 days)
If the assessment isn’t complete within the 30-day time period, there is a one-time option to extend the certification process for an additional 30 days. If, after the 60-day time period, a successful assessment isn't reached, the submission will be issued a fail and the process must start again.

Compliance Evidence

Where an application has a specific compliance requirement, additional information and documentary evidence will be required to assess conformance to the relevant compliance program. Certification analysts won't be subject-matter experts (SMEs) in all compliance programs, thus, this requirement will be fulfilled by accepting evidence of valid certifications conducted by reputable external third-party companies. These reputable companies must be members of international accreditation bodies for relevant compliance programs. See ISO Certification and Conformity Standards.

Before an external security standard/framework can be used to demonstrate conformance to any of the Microsoft 365 app certification controls, the analysts need to review all relevant documentation to determine its suitability as follows:

Standard Requirements
ISO 27001 A public facing version of the Statement of Applicability (SOA) and a copy of the ISO 27001 certificate issued will be required. The SOA summarizes your position on each of the 114 information security controls and will be used to identify if any exclusion of controls that aren't satisfactorily detailed in the ISO 27001 certificate. If this can't be determined by reviewing the public facing version of the SOA, the analyst might need access to the full SOA if ISO 27001 will be used to validate some of the Microsoft 365 App Certification Specification controls. In addition to validating the scope of the ISO 27001 assessment activities, the analysts will also confirm the validity of the audit company as described above.
PCI DSS A valid Level 1 Attestation of Compliance (AOC) document must be provided clearly identifying the in-scope application and system components. A self-assessment AOC will not be accepted as evidence of meeting security best practices. The AOC will be used to determine which of the Microsoft 365 App Certification Specification controls have been evaluated and confirmed as part of the PCI DSS assessment.
SOC 2 The SOC 2 (Type I or Type II) report must be current (within the last 12 months) to be used as evidence of conformity with any of the assessment controls within this Microsoft 365 App Certification Specification.

If a developer already has one of the supported security standards/frameworks, the following appendixes might be used to identify where potential gaps between the standard/framework and the Microsoft 365 App Certification exist as follows:

Framework Additional considerations
ISO 27001 Appendix C: Evidence Collection – Deltas for ISO 27001.
PCI DSS Appendix D: Evidence Collection – Deltas for PCI DSS.
SOC 2 Appendix E: Evidence Collection – Deltas for SOC 2.

Important

Analysts will try to align existing frameworks to the Microsoft 365 App Certification Specification; however, the supporting documentation may not provide enough assurance that compliance requirements were independently verified as part of the external audit/assessment.

Therefore the appendices should only be used as guides as some controls may be added to the deltas (gaps) once the analysts have reviewed supporting documentation.

Note

Although the above-mentioned external security standards/frameworks can be submitted as evidence to meet some of the Microsoft 365 App Certification controls, passing the Microsoft 365 App Certification doesn't mean that you will successfully pass an audit against those standards/frameworks. The Microsoft 365 App Certification Specification is only a small subset of those security standards/frameworks that allows Microsoft to gain a level of assurance in reference to your security posture.

Initial document submission

You will be required to submit supporting documentation to assist with the overall analysis. Your initial submission must include the data specified below:

Documentation Overview Documentation Details
Architecture diagrams A logical architecture diagram representing a high level overview of your app's supporting infrastructure provided for each hosting environment.
Data flow diagrams Flow diagrams detailing the following:
✓ Data flow from the user (including EUII and OII ).
✓ Data flow through any tiers of the application infrastructure.
✓ Diagrams highlighting where and what data is stored, how data is passed to external third parties, and how data is protected in transit over open/public networks and at rest.
API endpoint details API endpoint specifications detailing:
✓ Endpoint locations.
✓ Supported HTTP methods
✓ Required and optional parameters.
✓ Data type definitions for each parameter.
✓ Description of each parameter value received
Authentication models A description of the security properties of the authentication process and one or more of the following:
✓ Cookie-Based authentication.
✓ Token-Based authentication.
✓ Third party access (OAuth, API-token).
✓ OpenId.
SAML.
Data storage types Data storage and handling documents describing:
✓ To what degree EUII and OII is being received and stored
✓ The data retention period.
✓ Where data is stored.
✓ How data storage is minimized, audited, and deleted after the retention period.
Data Storage and Privacy Documentation describing how data encryption has been designed and implemented including:
✓ Encryption algorithms and protocols in use.
✓ Key type.
✓ Key scheme.
✓ Key algorithm.
✓ Key size/strength.
Data capture details Documentation detailing all data captured by your app including:
✓ Where data is captured.
✓ Why the data is being captured.
✓ How data is processed.
Compliance confirmation Supporting evidence for required security standards, frameworks, or regulations to be considered as part of the assessment. For example:
PCI DSS Attestation of Compliance (AOC).
SOC 2 Type I/Type II reports.
ISMS / IEC - 1S0/IEC 27001 Statement of Applicability (SoA) and Certification.

Evidence Collection Activities

To obtain adequate evidence and a level of assurance during the certification process, the evidence submission requirements will include some or all of the following:

  • Manual inspection.
  • Observation.
  • Confirmation.
  • Analytical procedures.

The evidence-gathering process involves the following steps:

  • Carrying out the audit procedures or tests and/or gathering evidence.
  • Analyzing evidence and drawing conclusions, which may also involve evaluating performance against the specification criteria.
  • Making decisions about whether additional information is required and can be obtained or whether sufficient evidence exists.

Analysts will first review the evidence provided from the initial documentation submission and the Publisher attestation report to identify appropriate lines of inquiry, sampling size, and the need for further evidence to be obtained either through either a question and answer (Q&A) session via screen share/conference call, an email request for evidence through screenshots, or via your provision of further requested physical documentation.

At least once during the evidence collection processes, you will be required to screen share with the analysts to show the application registration page within the Graph API allowing the assessors to observe permission types and permissions requested.

Where possible and to reduce the amount of time required in the Q&A sessions, any or all of the documentation detailed in the Initial Documentation Submission should be provided in advance.

When the additional documentation can't be provided in advance of the Q&A, you'll be required to have access to in-scope systems and supporting evidence to allow for any or all of the following to be observed:

  • Configuration Files.
  • System Configuration.
  • Change tickets.
  • Change control records.
  • Current system state.
  • System Reports.

App certification criteria and process

Your app, supporting infrastructure, and supporting documentation will be assessed across the following security domains:

  1. Application Security.
  2. Operational Security / Secure Deployment.
  3. Data Handling Security and Privacy.
  4. Compliance Checks.

Each of these security domains include specific key controls encompassing one or more specific requirements that will be evaluated as part of the assessment process. To ensure that Microsoft 365 App Certification is inclusive to developers of all sizes, each of the four security domains is assessed using a scoring system to determine an overall score from each of the domains. Scores for each of the Microsoft 365 App Certification controls are allocated between 1 (low) and 3 (high) based upon the perceived risk of that control not being met. Each of the four security domains will have a minimum percentage mark to be deemed a pass. Certain elements of this specification include some automatic fail criteria:

 ✓ API permissions not following the principle of least privilege (PoLP).
 ✓ No penetration testing report when it is required.  ✓ No anti-malware defenses.
 ✓ Multi-Factor authentication not being used to protect administrative access.
 ✓ No patching processes.
 ✓ No suitable GDPR privacy notice.

Application Security

An adequate review of the inherent risks associated with your app and supporting environment is essential to the testing process. The “Test Specification” section provides guidance on selecting a suitable testing option to ensure that the coverage is adequate.

Test Specification

Pen testing
.
Application and infrastructure penetration testing is expected to take place annually (every 12 months) and conducted by a reputable company. Remediation of identified critical and high-risk vulnerabilities is required within three months of the conclusion of the penetration testing.

Retesting of identified vulnerabilities by an independent firm isn't required — remediation and self-review is sufficient. The Microsoft 365 App Certification process can still start with an expired penetration test report, providing a new penetration test has been scheduled to be completed within 15-months from the date of the initial penetration test report not including subsequent retests.

As part of the Microsoft 365 App certification Specification, Microsoft reserves the right to request a copy of the report for review once it has been completed. If the report isn't provided, the certification can be revoked.
DAST testing
.
The chosen DAST tool should ensure:
✓ All application are scanned from both an authenticated and unauthenticated perspective.
✓ Evidence of coverage including a list of URI paths scanned and sample request/response data to ensure the scan was properly authenticated.
✓ Inclusion of all findings even those you consider to be false positives.
✓ A list of security checks performed during the scan.
✓ Scan coverage of all web application vulnerability classes.
SAST testing
SAST audit reports should include security hot spots and vulnerabilities identified in assessed source code listing the assets (file path and file name), language, and lines of code assessed.

Vulnerability Assessment Review

Pen testing and DAST and SAST reports will be reviewed to ensure there are no vulnerabilities that meet the following automatic failure criteria:
Presence of an unsupported operating system.
Presence of default, enumerable, or guessable administrative accounts.
Presence of SQL injection risks.*
Presence of cross-site scripting.*
Presence of directory traversal (file path) vulnerabilities.*
Presence of HTTP vulnerabilities, e.g., Header response splitting, Request smuggling, and Desync attacks.*
Presence of source code disclosure (including LFI).*
Any critical or high score as defined by the CVSS patch management guidelines.
**Any significant technical vulnerability that might be readily exploited to compromise significant EUII or OII*.
*Despite your app's CVSS score.

App Updates and modifications

If your app undergoes significant changes within the interim certification period, DAST and SAST results will be reviewed in place of a pen test report. Non-significant changes won't require DAST, SAST, or pen testing.

Teams Apps

Connectors
Pen, DAST, and SAST scans aren't required. Connectors have no risk of sensitive data being leaked and don't disclose information about the recipient.
Bots and Messaging Extensions
Annual pen testing is required. Both DAST and SAST are required for interim updates to bots and messaging extensions that receive sensitive data. SAST is preferred over DAST scans where app permission requests include receipt and/or storage of sensitive data.
Tabs
Annual pen testing is required. Both DAST and SAST are required for interim updates

Operational Security/Secure Deployment

This domain measures the alignment of your app's supporting infrastructure and deployment processes with security best practices.

Test Specifications

Malware protection
Anti-virus (also including anti-malware products) must be deployed on all in-scope system components and meet the following:
­✓ Anti-virus software is running on all system components within scope.
✓ Anti-virus software is kept up to date (within 30 days).
✓ Anti-virus signatures are kept up to date (within 1 day).
✓ Either on-access scanning and/or periodic scans with notifications must be configured. Where on-access scanning is used, weekly scans can be configured, however if on-access scanning isn't configured, this needs to be daily scanning.
✓ Anti-virus software must be configured as follows.
 ◼ Block known malware.
 ◼ Either Quarantine and Alert or simply Alert on suspected malware.
✓ Policies and procedures must be in place to promote anti-virus good practices.
or
Application controls must be configured on all in-scope system to meet the following:
✓ All allowed applications permitted to execute on in-scope system components must be approved by the organization.
✓ The organization must maintain a complete list of approved applications with business justification for the application.
✓ Specific application control mechanisms must be fully documented; i.e. whitelisted locations; code signing, etc.
­ ✓ Documented process for application approvals must be in place and auditable.
Patch management
You must have documented patching policies and procedures in place that ensure patching is conducted in a timely manner. A process must be in place that identifies, ranks, and patches new security vulnerabilities based on the CVSS Recommended Risk Ranking scores and CVSS Vectors below:
Recommended Risk Ranking Scores
Critical: 9.0 - 10.0.
High: 7.0 - 8.9.
Medium: 4.0 - 6.9.
Low: 0.0 - 3.9.
CVSS Vectors
attack vector | low only.
attack complexity | low only.
privileges required | none only.
user interaction | none only.
exploit code maturity | functional or high.
report confidence | confirmed.
Patching
✓ Any Critical, High, or Medium risk issue, as defined by the CVSS Vectors above, needs to be patched within a pre-determined and documented period which represents the minimal window of time before the issue is resolved.
✓ Any Low, Medium, High or Critical issue that doesn't match the CVSS Vectors above can be patched within normal patching activity windows.
✓ Policies and procedures detailing how patching is conducted must be in place and must include all applicable operating systems, applications and software components used within the environment.
✓ Unsupported software components and operating systems must not be used within the environment. Supporting policies must be in place to ensure unsupported software components / operating systems will be removed from the environment and a process to identify when software components go end-of-life must be in place.
Vulnerability scanning Vulnerability scanning must include:
✓ Quarterly external vulnerability scanning measured against the public footprint of the in-scope environment.
✓ Quarterly authenticated internal vulnerability scanning measured against in-scope system components.
✓ A documented vulnerability remediation policy detailing the timeline to fix vulnerabilities based upon the CVSS Recommended Risk Ranking and CVSS Vectors (see above).
✓ A remediation policy to ensure system components are free from known vulnerabilities.
✓ Ongoing re-scans until identified Recommended Risk Ranking and CVSS Vectors are remedied within the required timeline.
Firewalls
Your infrastructure will be expected to have a firewall (or equivalent where Cloud services are being consumed) on all internet connections exposing the in-scope environment. Firewalls must be configured as follows:
✓ Installed on the boundaries (public network) of the in-scope environment.
✓ Installed between a DMZ (Demilitarized Zone) and the trusted networks.
✓ All public access must terminate in a DMZ (Demilitarized Zone).
✓ Default administrative credentials must be changed, prior to installation into the live environment.
✓ ­All traffic permitted through the firewalls (in either direction) must go through an authorization process and all protocols, services and ports must be fully documented with business justifications.
✓ ­Strong cryptography must be enabled on all Firewall non-console administrative interfaces
✓ Multi-factor authentication enabled where Firewall administrative interfaces are exposed to the internet.
✓­ Firewall reviews conducted at least every six months
Web Application Firewall (WAF). Additional credit will be given if a WAF or equivalent measure is deployed to help protect against web application threats and vulnerabilities. If present, supporting policies and procedures should be in place along with the following required controls for review:
✓ WAF operating in active defense mode (automatically blocking identified attacks) or in monitoring mode (actively monitoring/investigating alerts)
✓ WAF configured to support SSL offloading.
✓ WAF configured as per the OWASP Core Rule Set (2.2.9 or 3.0) to protect against the majority of the following:
 ◼ Protocol and encoding issues.
 ◼ Header injection, request smuggling, and response splitting.
 ◼ File and path traversal attacks.
 ◼ Remote file inclusion (RFI) attacks.
 ◼ Remote code execution attacks.
 ◼ PHP-injection attacks.
 ◼ Cross-site scripting attacks.
 ◼ SQL-injection attacks.
 ◼ Session-fixation attacks.
Change control
Change control policies and procedures must be in place to ensure that changes are implemented in a manner aimed at maintaining the security, stability, and integrity of the environment.The following control criteria are required:
✓ Separation of duties—development and test environments must be separate from the production environments.
✓ Sensitive data from production environments must not be used within development/test environments.
✓ All changes must be tested within a test/development environment prior to being introduced into the production environment.
✓ Confirmation that all testing completed successfully.
✓ Change requests raised and authorized PRIOR to going into production.
✓ Change requests must include, at a minimum, the following:
 ◼ Documentation of impact.
 ◼ Details of functionality testing confirming that the change has been successful and had no adverse impact.
 ◼ Documented back-out procedures.
✓ Functionality testing after the change to confirm success.
✓ Change requests confirmed as complete AFTER successful functionality testing.
Event logging, reviewing, and alerting
Event logging
Logging configuration coverage must include ALL in-scope system components and applications including malware protection software. The following must be logged:
 ◼ User access to system components and the application.
 ◼ All actions taken by a high-privileged user.
 ◼ Invalid logical access attempts.
­Event logs that include the following:
 ◼ User.
 ◼ Type of event.
 ◼ Date and time.
 ◼ Success/Failure indicator.
 ◼ Label to identify the affected system.
­Time-synchronization must be used across all in-scope system components to aid in forensic investigations.
­ Public facing systems (within the DMZ) must write logs to a secured centralized logging repository. The centralized logging repository must not be within the DMZ.
­ Audit trails must be secured to ensure data cannot be altered by a threat actor. Access to the centralized logging repository must be limited to authorized personnel only.
­ Logs should be immediately available for 30 days. Logging data should be retained for a minimum of 90 days.
Reviewing
Review processes as well as supporting policies and procedures must meet the following:
✓ Perform daily log reviews or utilize automated log analysis and alerting technology to review events from all in-scope system components identifying any exceptions and anomalies or potential security events.
✓ Follow up on any potential security events.
Alerting
Alerting processes as well as supporting policies and procedures must meet the following:
✓ Logged security events will trigger an immediate alert.
✓ ­Staff must be available at all times (24/7) to react to alerts.
Account management
System component and application account management as well as supporting policies and procedures must meet the following:
✓ Default credentials (Vendor or Developers) are either disabled or removed across all in-scope system components.
✓ Account creation, modification and deletion must go through an established approval process.
✓ Account roles and privileged access modifications are monitored through logging mechanisms.
✓Authorization schemes are replay-resistant (e.g. utilize Kerberos, OTP) for network access to privileged accounts.
✓ Accounts that haven't been used for over 3 months must be disabled or deleted.
✓ Strong password policies or other suitable mitigation must be configured to protect user credentials. The following password policy should be used as a guideline:
✓ Minimum password length of eight characters.
✓ Account lockout threshold of no more than 10 attempts
✓ Password history of a minimum of five passwords.
✓ Enforcement of the use of strong passwords.
✓ Unique user accounts are issued to each user, no shared accounts are to be used.
✓ Least privilege principles should apply to all users, the mechanism used to achieve this should be documented (i.e. the use of groups).
✓ Remote Access:
 ◼ MFA must be used on all remote access solutions.
 ◼ Remote access solutions must utilize a data in transit protection profile that meets or exceeds the data-in-transit configuration profile as described in Appendix A.
Risk management
A risk-assessment methodology must be developed and conducted that includes the following:
✓ A formally defined process.
✓ Performed at least annually.
✓ Identifies all assets and all threats and vulnerabilities against said assets.
✓ Impact and likelihood matrices.
✓ Creation of a risk register and corresponding risk treatment plan.
Incident response
A thorough incident response plan is required and should include but aren't limited to:
✓ Specific incident response procedures for expected threat models.
✓ Demonstrates incident handling capabilities that aligns with the NIST Cybersecurity Framework (Identify, Protect, Detect, Respond, Recover).
✓ Documented communications process, ensuring the timely notification of all key stakeholders and any relevant external bodies such as; payment brands/acquirers, regulatory bodies and supervisory authorities (GDPR).
✓ At a minimum, coverage of the in-scope systems components and application.
✓ Inclusion of any mandated reporting requirements; for example, 72 hours reporting to a supervisory authority for GDPR.
✓ Annual training for members of the incident response team.

Data Handling Security and Privacy

Data in transit between the application user, intermediary services, and application developer systems will be required to be protected by encryption through a TLS connection supporting a minimum of TLS v1.1. See Appendix A.

Where your application retrieves and stores sensitive data; such as, conversation contents, identity information, and channels lists, you will be required to implement a data storage encryption scheme that follows the specification as defined in Appendix B.

Test Specifications

Data Retention and Disposal
Sensitive data storage should be kept to a minimum by implementing data retention and disposal policies, procedures and processes that minimally include:
✓ Document and limit data storage amount and retention time to that that is required for legal, regulatory, and/or business requirements.
✓ Document and deploy processes for secure deletion of sensitive data when no longer needed.
✓ Document and deploy a quarterly process for identifying and securely deleting stored sensitive data that exceeds the defined retention period.
Data Access Management
Limiting data access to those with a legitimate business reason for that access helps an organization prevent mishandling of sensitive data through inexperience or malice. Sensitive data, received by the developer application, requires documented approval (electronic or in writing) for authorized parties at all access levels and must include a listing of approved and verified privileges that demonstrate the policy incorporates the specified requirements as follows:
✓ Defining access needs and privilege assignments only to roles that specifically require such privileged access.
✓ Restricting access to privileged user IDs to the least privileges necessary to perform job responsibilities.
Data Sharing
Any sensitive data shared with third-parties will require the developer to have appropriate interconnection security agreements in place that meet or exceed the data handling and privacy requirements presented here including agreements to protect data in transit and at rest according to the encryption profiles described in Appendix B.
GDPR
As part of the Microsoft 365 app certification process, you must demonstrate adherence to the GDPR framework, either by:
✓ Providing an independent review of the GDPR conformance by an experienced external audit company. You will be required to submit the report for review or allow the analyst to view the report. The report should provide enough details to not only validate the external auditor’s assessment but also provide enough confidence that the external review has confirmed conformance to the GDPR.
or
✓ Submitting further evidence to provide additional assurance of your commitment to data privacy laws. This review will only cover some of the basic GDPR requirements since a full GDPR/Data Privacy review could take a significant time to cover.
Where an independent GDPR report isn’t available, the following must be in place to be reviewed as part of the Microsoft 365 app certification assessment:
✓ A documented subject access request (SAR) process designed to meet the requests of customers and meet the thirty-day requirement of the GDPR. It is recommended that adequate data discovery tooling is in place to ensure a SAR is fulfilled within these time frames, where these tools aren't used, you will need to demonstrate how this works and demonstrate how the processes are able to guarantee discovery of all data subject’s information.
✓ Privacy Notices must be present on the website and contain the following information:
 ◼ Organizations contact details.
 ◼ Type of personal data being processed.
 ◼ Lawfulness of processing personal data (Article 6).
 ◼ Details of data subject's rights:
  □ Right to be informed (Articles13 and 14).
  □ Right of access by the data subject (Article 15).
  □ Right of rectification (Article 16).
  □ Right to erasure (Article 17).
  □ Right to restriction of processing (Article 18).
  □ Right to data portability (Article 20).
  □ Right to object (Article 21).
  □ Rights in relation to automated decision-marking, including profiling (Article 22).
✓ Information sharing with third-parties must have agreements in place to ensure processing of data subject’s data are in line with data privacy laws.

Compliance Checks

If external security standards/frameworks have been included within the Publisher Attestation, the certification analysts will need to authenticate the validity of those standards/frameworks as part of the assessment.

Test Specifications

Evidence of valid certifications by accredited third-party auditors to ensure your app is currently in compliance and the scope is consistent with the in-scope solution. Common compliance standards include:
ISMS/ IEC - IS0/IEC 27001 specification
PCI DSS
SOC 2

Appendix A

TLS Profile configuration requirements

All network traffic, whether within a virtual network, cloud service, or a data center, must be protected with TLS or other applicable protocol. Exceptions to this requirement are:

  • HTTP-to-HTTPS redirect. Your app is allowed to respond over HTTP to redirect clients to HTTPS, but the response must not contain any sensitive data (cookies, headers, content). No other HTTP responses other than redirects to HTTPS and responding to health probes are allowed. See below.
  • Health probes. Your app is allowed to respond to health probes over HTTP only if HTTPS health probes aren't supported by the checking party.
  • Certificate access. Access to CRL, OCSP, and AIA endpoints for the purposes of certificate validation and revocation checking is allowed over HTTP.
  • Local communications. Your app is allowed to use HTTP (or other non-protected protocol) for communications that don't leave the operating system, e. g. connecting to a web server endpoint exposed on localhost.

Appendix B

Encryption Profile Configuration Requirements

Only cryptographic primitives and parameters are permitted as follows:

Symmetric cryptography.

Encryption.

 ✓ Only AES, BitLocker, Blowfish or TDES are allowed. Any of the supported key lengths >=128 are allowed (128, 192, and 256 bits) and may be used (256-bit keys are recommended).

 ✓ Only CBC mode is allowed. Every encryption operation must use fresh, randomly generated initialization vector (IV).

 ✓ Use of Stream ciphers, such as RC4, isn't allowed.

Hash functions.

 ✓ All new code must use SHA-256, SHA-384, or SHA-512 (collectively referred to as SHA-2). Output may be truncated to no less than 128 bits.

 ✓ SHA-1 may only be used for compatibility reasons.

 ✓ Use of MD5, MD4, MD2 and other hash functions isn't allowed, even for non-cryptographic applications.

Message authentication.

 ✓ All new code must use HMAC with one of the approved hash functions. Output of HMAC may be truncated to no less than 128 bits.

 ✓ HMAC-SHA1 may only be used for compatibility reasons.

 ✓ HMAC key must be at least 128 bits. 256-bit keys are recommended.

Key derivation.

 ✓ PBKDF2 is allowed for deriving cryptographic keys from low-entropy strings (such as passwords provided by a user). Number of iterations must be at least 10'000.

 ✓ SP800-108 with approved HMAC in counter mode is allowed for deriving cryptographic keys from a high-entropy shared secrets.

Asymmetric algorithms.

Encryption.

 ✓ RSA is allowed. Key must be at least 2048 bits and OAEP padding must be used. Use of PKCS padding only allowed for compatibility reasons.

Signatures.

 ✓ RSA is allowed. Key must be at least 2048 bits and PSS padding must be used. Use of PKCS padding only allowed for compatibility reasons.

 ✓ ECDSA is allowed. Key must be at least 256 bits. NIST P-256, P-384 or P-521 curve must be used.

Key exchange.

 ✓ ECDH is allowed. Key must be at least 256 bits. NIST P-256, P-384 or P-521 curve must be used.

 ✓ RSA is allowed. Key must be at least 2048 bits and OAEP or padding or KEM construct must be used.

Appendix C

Evidence Collection – Delta for ISO 27001

Where the developer has already attained ISO27001 compliance, the following delta’s (gaps) not wholly covered by ISO27001 will need to be reviewed as part of this M365 app certification.

Note

As part of the Microsoft assessment, the analyst will determine if any of the mapped ISO27001 controls weren't included as part of the ISO27001 assessment and may sample controls that were found to be included. Any requirements missing from the ISO27001 will need to be included within the Microsoft assessment activities.

Malware Protection – Anti Virus.

If malware Protection is in place through use of application control and is attested to within ISO27001 Report no further investigation is necessary. If no application control is in place, Microsoft will need to identify and assess evidence of application control mechanisms to prevent detonation of malware within the environment. This will require the developer to:

  • Demonstrate that anti-virus software is running across all sampled system components.

  • Demonstrate that anti-virus is configured across all sampled system components to either automatically block malware, to quarantine & alert or to alert.

Patch Management – Patching.

As ISO27001 audits don't specifically assess this category, this will require the developer to:

  • Identify and demonstrate the minimal window of time in which Critical/High and Medium risks meeting the defined attack vector will be patched.

Vulnerability Scanning.

As ISO27001 audits don't specifically assess this category, this will require the developer to:

  • Demonstrate that quarterly internal and external vulnerability scanning is conducted.

  • Confirm supporting documentation is in place for vulnerability remediation based on risk ranking and in line with the specification as follows:

 ✓ Fix all Critical and Highs risk issues in-line with the risk ranking for Internal scanning.

 ✓ Fix all Critical, Highs and Medium risk issues in-line with the risk ranking for external scanning.

 ✓ Demonstrate that remediation is conducted in-line with the documented vulnerability remediation policy.

Firewall – Firewalls (or equivalent technologies).

As ISO27001 audits don't specifically assess this category, this will require the developer to:

  • Demonstrate that firewalls are installed on the boundary of the in-scope environment.

  • Demonstrate that firewalls are installed between the DMZ and trusted networks.

  • Demonstrate that all public access terminates in the DMZ.

  • Demonstrate that default administrative credentials are changed prior to installation into the live environment.

  • Demonstrate that all permitted traffic through the firewall(s) goes through an authorization process which results in the documentation of all traffic with a business justification.

  • Demonstrate that all firewalls are configured to drop traffic not explicitly defined.

  • Demonstrate that firewalls support only strong cryptography on all non-console administrative interfaces.

  • Demonstrate that firewall's non-console administrative interfaces exposed to the Internet support MFA.

  • Demonstrate that firewall rule reviews are conducted at least every 6 months.

Firewall – Web Application Firewalls (WAF).

Additional credit will be provided if a WAF or similar is deployed to help protect against the myriad of web application threats and vulnerabilities that the application can be exposed to. When a WAF or similar is present, this will require the developer to:

  • Demonstrate the WAF is configured in active defense mode or monitoring more with alerting.

  • Demonstrate the WAF is configured to support SSL Offloading.

  • Is configured as per the OWASP Core Rule Set (2.2.9 or 3.0) to protect against the majority of the following attack types:

 ✓ Protocol and encoding issues.

 ✓ Header injection, request smuggling, and response splitting.

 ✓ File and path traversal attacks.

 ✓ Remote file inclusion (RFI) attacks.

 ✓ Remote code execution attacks.

 ✓ PHP-injection attacks.

 ✓ Cross-site scripting attacks.

 ✓ SQL-injection attacks.

 ✓ Session-fixation attacks.

Change Control.

As ISO27001 audits don't specifically assess some elements of Change Request processes, this will require the developer to:

  • Demonstrate that change requests have the following details:

 ✓ Documented impact.

 ✓ Details of what functionality testing is to be conducted.

 ✓ Details of any back-out procedures.

  • Demonstrate that functionality testing is conducted after changes are completed.

  • Demonstrate that change requests are signed off after functionality testing is conducted.

Event Logging.

As ISO27001 audits don't specifically assess some elements of security event logging processes, this will require the developer to:

  • Demonstrate that public facing systems are logging to a centralized logging solution which isn't within the DMZ.

  • Demonstrate how a minimum of 30 days’ worth of logging data is immediately available, with 90 days being retained.

Reviewing (Logging Data).

As ISO27001 audits don't specifically assess some elements of this category, this will require the developer to:

  • Demonstrate how daily log reviews are conducted and how exceptions and anomalies are identified showing how these are handled.

Alerting.

As ISO27001 audits don't specifically assess some elements of this category, this will require the developer to:

  • Demonstrate how security events are configured to trigger alerts for immediate triage.

  • Demonstrate how staff are available 24/7 to respond to security alerts.

Account Management.

As ISO27001 audits don't specifically assess some elements of account management processes, this will require the developer to:

  • Demonstrate how the authorization mechanisms are implemented to mitigate replay attacks (e.g. MFA, Kerberos).

  • Demonstrate how accounts that haven't been used in 3 months are either disabled or deleted.

  • Strong password policies or other suitable mitigations must be configured to protect user credentials. The following minimum password policy should be used as a guideline;

 ✓ Minimum password length of 8 characters.

 ✓ Account lockout threshold of no more than 10 attempts.

 ✓ Password history of a minimum of five passwords.

 ✓ Enforcement of the use of strong passwords.

  • Demonstrate that MFA is configured for all remote access solutions.

  • Demonstrate that strong encryption is configured on all remote access solutions.

Risk Management.

As ISO27001 audits don't specifically assess some elements of risk assessment processes, this will require the developer to:

  • Demonstrate that a formal risk management process is established.

Incident Response.

As ISO27001 audits don't specifically assess some elements of incident response policies and processes, this will require the developer to:

  • Demonstrate that the incident response plan/procedure includes:

 ✓ Specific response procedures for expected threat models.

 ✓ Incident handling capabilities aligning to NIST Cybersecurity Framework (Identify, Protect, Detect, Respond, Recover).

 ✓ The IRP covers the in-scope systems.

 ✓ Annual training for the incident response team.

Appendix D

Evidence Collection – Deltas for PCI DSS

Where the developer has already attained PCI DSS compliance, the following delta’s (gaps) not wholly covered by PCI DSS will need to be reviewed as part of this N365 app certification.

Note

As part of the Microsoft assessment, the analyst will determine if any of the mapped PCI DSS controls weren't included as part of the PCI DSS assessment and may sample controls that were found to be included. Any requirements missing from the PCI DSS will need to be included into the Microsoft assessment activities.

Malware Protection - Application Control.

If malware protection is in place through use of anti-virus and is attested to within PCI DSS Report no further investigation is necessary. If no anti-virus is in place, Microsoft will need to identify and assess evidence of application control mechanisms to prevent detonation of malware within the environment. This will require the developer to:

  • Demonstrate how the application approval is conducted and confirm that this is completed.

  • Demonstrate that a complete list of approved applications with business justification exists.

  • Provide or demonstrate supporting documentation is in place detailing how application control software is configured to meet specific application control mechanisms (i.e. whitelisting, code signing, etc.).

  • Demonstrate that across all sampled system components, application control is configured as documented.

Patch Management – Risk Ranking.

As PCI DSS audits don't specifically assess this category, this will require the developer to:

  • Demonstrate how risk ranking of vulnerabilities is conducted.

Patch Management – Patching.

As PCI DSS audits don't specifically assess this category, this will require the developer to:

  • Identify and Demonstrate the MINIMAL WINDOW of time in which Critical/High and Medium risks meeting the defined attack vector will be patched.

Vulnerability Scanning.

As PCI DSS audits don't specifically assess this category, this will require the developer to:

  • Demonstrate that remediation is conducted in-line with the documented vulnerability remediation policy.

Firewall – Firewalls (or equivalent technologies).

As PCI DSS audits don't specifically assess this category, this will require the developer to:

  • Demonstrate that firewalls support only strong cryptography on all non-console administrative interfaces.

  • Demonstrate that firewall's non-console administrative interfaces exposed to the Internet support MFA.

Additional credit will be provided if a Web Application Firewall (WAF) or similar is deployed to help protect against the myriad of web application threats and vulnerabilities that the application can be exposed to. When a WAF or similar is present, this will require the developer to:

  • Demonstrate the WAF is configured in active defense mode or monitoring more with alerting.

  • Demonstrate the WAF is configured to support SSL offloading.

  • Is configured as per the OWASP Core Rule Set (2.2.9 or 3.0) to protect against the majority of the following attack types:

 ✓ Protocol and encoding issues.

 ✓ Header injection, request smuggling, and response splitting.

 ✓ File and path traversal attacks.

 ✓ Remote file inclusion (RFI) attacks.

 ✓ Remote code execution attacks.

 ✓ PHP-injection attacks.

 ✓ Cross-site scripting attacks.

 ✓ SQL-injection attacks.

 ✓ Session-fixation attacks.

Change Control.

As PCI DSS audits don't specifically assess some elements of Change Request processes, this will require the developer to:

  • Demonstrate that change requests are raised before being made in production environments.

  • Demonstrate that changes are authorized before going into production.

  • Demonstrate that functionality testing is conducted after changes are completed.

  • Demonstrate that change requests are signed off after functionality testing is conducted.

Account Management.

As PCI DSS audits don't specifically assess some elements of account management processes, this will require the developer to:

  • Demonstrate how the authorization mechanisms are implemented to mitigate replay attacks (e.g. MFA, Kerberos).

  • Strong password policies or other suitable mitigations must be configured to protect user credentials. The following minimum password policy should be used as a guideline;

 ✓ Minimum password length of 8 characters.

 ✓ Account lockout threshold of no more than 10 attempts.

 ✓ Password history of a minimum of five passwords.

 ✓ Enforcement of the use of strong passwords.

  • Demonstrate that strong encryption is configured on all remote access solutions.

Risk Management.

As PCI DSS audits don't specifically assess some elements of risk assessment processes, this will require the developer to:

  • Demonstrate the risk assessment includes impact and likelihood matrices.

Incident Response.

As PCI DSS audits don't specifically assess some elements of incident response policies and processes, this will require the developer to:

  • Demonstrate Incident handling capabilities align to NIST Cybersecurity Framework (Identify, Protect, Detect, Respond, Recover).

Appendix E

Evidence Collection - Deltas for SOC 2

Where the developer has already attained SOC 2 compliance, the following delta’s (gaps) not wholly covered by SOC 2 will need to be reviewed as part of this M365 app certification.

Note

As part of the Microsoft assessment, the analyst will determine if any of the mapped SOC2 controls weren't included as part of the SOC2 assessment and may sample controls that were found to be included. Any requirements missing from the SOC2 will need to be included into the Microsoft assessment activities.

Malware Protection - Application Control.

If malware protection is in place through use of anti-virus and is attested to within SOC 2 Report no further investigation is necessary. If no anti-virus is in place, Microsoft will need to identify and assess evidence of application control mechanisms to prevent detonation of malware within the environment. This will require the developer to:

  • Provide or demonstrate supporting documentation is in place detailing how application control software is configured to meet specific application control mechanisms (i.e. whitelisting, code signing, etc.).

  • Demonstrate how the application approval is conducted and confirm that this is completed.

  • Demonstrate that a complete list of approved applications with business justification exists.

  • Demonstrate that across all sampled system components, application control is configured as documented.

Firewall – Firewalls.

As SOC 2 audits don't specifically assess change controls to firewall access control lists, this will require the developer to:

  • Demonstrate that all permitted traffic through the firewall(s) goes through an authorization process which results in the documentation of all traffic with a business justification.

  • Demonstrate that firewall rule reviews are conducted at least every six months.

Additional credit will be provided if a Web Application Firewall (WAF) or similar is deployed to help protect against the myriad of web application threats and vulnerabilities that the application can be exposed to. When a WAF or similar is present, this will require the developer to:

  • Demonstrate the WAF is configured in active defense mode or monitoring more with alerting.

  • Demonstrate the WAF is configured to support SSL offloading.

  • Is configured as per the OWASP Core Rule Set (2.2.9 or 3.0) to protect against the majority of the following attack types:

 ✓ Protocol and encoding issues.

 ✓ Header injection, request smuggling, and response splitting.

 ✓ File and path traversal attacks.

 ✓ Remote file inclusion (RFI) attacks.

 ✓ Remote code execution attacks.

 ✓ PHP-injection attacks.

 ✓ Cross-site scripting attacks.

 ✓ SQL-injection attacks.

 ✓ Session-fixation attacks.

Change Control.

As SOC 2 audits don't specifically assess some elements of Change Request processes, this will require the developer to:

  • Demonstrate how development / test environments are separate from the production environment enforcing separation of duties.

  • Demonstrate how live data isn't used within the development / test environments.

  • Demonstrate that functionality testing is conducted after changes are completed.

  • Demonstrate that change requests are signed off after functionality testing is conducted.

Event Logging.

As SOC 2 audits don't specifically assess some elements of security event logging processes, this will require the developer to:

  • Demonstrate how, on all system components within the sample set the following system are configured to log the following events:

 ✓ User access to system components and the application(s).

 ✓ All actions taken by a high privileged user.

 ✓ Invalid logical access attempts.

Demonstrate that logged events contain; at a minimum, the following information:

 ✓ User.

 ✓ Type of Event.

 ✓ Date and Time.

 ✓ Success/Failure indicator.

 ✓ Label to identify the affected system.

  • Demonstrate that all system components within the sample set are configured to utilize time-synchronization and that these are the same as the primary/secondary time servers.

  • Demonstrate that public facing systems are logging to a centralized logging solution which isn't within the DMZ.

  • Demonstrate how the centralized logging solution is protected from unauthorized tampering of logging data.

  • Demonstrate how a minimum of 30 days’ worth of logging data is immediately available, with 90 days’ or more being retained.

Account Management.

As SOC2 audits don't specifically assess some elements of account management processes, this will require the developer to:

  • Demonstrate how the authorization mechanisms are implemented to mitigate replay attacks (e.g. MFA, Kerberos).

  • Demonstrate how accounts that haven't been used in 3 months are either disabled or deleted.

  • Strong password policies or other suitable mitigations must be configured to protect user credentials. The following minimum password policy should be used as a guideline:

 ✓ Minimum password length of 8 characters.

 ✓ Account lockout threshold of no more than 10 attempts.

 ✓ Password history of a minimum of 5 passwords.

 ✓ Enforcement of the use of strong passwords.

  • Demonstrate that unique user accounts are issued to all users.

Risk Management.

As SOC2 audits don't specifically assess some elements of risk assessment processes, this will require the developer to:

  • Demonstrate that a formal risk assessment is conducted at least annually.

Incident Response.

As SOC2 audits don't specifically assess some elements of incident response policies and processes, this will require the developer to:

  • Demonstrate that the incident response plan/procedure includes:

 ✓ Specific response procedures for expected threat models.

 ✓ Documented communications process to ensure timely notification of key stakeholders (payment brands/acquirers, regulatory bodies, supervisory authorities, directors, customers, etc.

Learn more

Microsoft 365 App Certification Overview
Microsoft 365 App Certification — Publisher Attestation
Microsoft 365 App Certification guide for enterprise organizations

Glossary

AIA

Authority Information Access is a service location descriptor used to find the certificate of the issuing certificate authority.

CRL

Certificate Revocation List provide a means for a Secure Sockets Layer (SSL) endpoint to verify that a certificate received from a remote host is valid and trustworthy.

CVSS score

Common Vulnerability Scoring System is a published standard that measures vulnerability and calculates a numerical score based on its severity.

CVSS patch management guidelines

  • Critical (9.0 - 10.0)
  • High (7.0 - 8.9)
  • Medium (4.0 - 6.9)
  • Low (0.0 - 3.9)

DAST testing

Dynamic Analysis Security Testing is the process of testing an application in its operating state for security vulnerabilities

DMZ

Demilitarized zone is a physical or logical intermediate network that interacts directly external or non-propriety networks while keeping the host's internal, private network separate and isolated.

EUII

End-user identifiable information.

GDPR

General Data Protection Regulation is a European Union (EU) privacy and data protection regulation for all EU citizens’ data regardless of where your application site is located.

IEC

International Electrotechnical Commission.

ISMS

Information Security Management System.

ISO 27001

An information security management system specification framework for all technical controls in an organizations risk management policies and procedures processes.

LFI

Local File Inclusion allows an attacker to include files on a server through the web browser.

NIST

The National Institute of Standards (NIST), a non-regulatory agency of the U.S. Department of Commerce provides guidance for private sector organizations in the US to assess and approve their ability to prevent, detect, and respond to cyber attacks.

Non-Significant changes

  • Minor Bug fixes.
  • Minor performance improvements.
  • Operating systems/libraries/client and server application patches.

OCSP

Online Certificate Status Protocol is used to check the revocation status of X.509 digital certificates.

OII

Organizational identifiable information.

OWASP

Open Web Application Security Project.

PCI DSS

Payment Card Industry Data Security Standard, an organization that maintains standards for the safety of cardholder data worldwide.

Pen testing

Penetration testing is a method of testing a web app by simulating malicious attacks to find security vulnerabilities that an attacker could exploit.

SAML

Security Assertion Markup Language is s an open standard for exchanging authentication and authorization data between the user, the identity provider and the service provider.

SAST testing

Static Application Security Testing is the process of examining an app’s source code for possible security flaws.

Sensitive Data

  • Access control data.
  • Customer content.
  • End-user identity information.
  • Support data.
  • Public personal data.
  • End-user pseudonymous information.

Significant changes

  • Relocation of the hosting environment.
  • Addition of capabilities and /or extensions to your app.
  • Updates to your app that capture additional sensitive Data.
  • Changes to your app's data flows or authorization models
  • Addition of API endpoints or API endpoint functions.

SOC 2

Service Organization Control 2, a technical auditing procedure comprised of five Trust Service Principles to ensure that service providers securely manage the data and privacy for an organization's clients.

SSL

Secure Sockets Layer.

TLS

Transport Layer Security.