When an unhandled server-side exception occurs in Dynamics 365 Online (model-driven apps, including Customer Service, Sales, and Field Service), the platform returns the standard ASP.NET Runtime Error page to the end user. This page contains static boilerplate text that references web.config and the configuration element.

This is the secure default. No stack traces, connection strings, or application-level sensitive data are exposed. The page is the generic "Remote" mode error response defined by the ASP.NET customErrors behavior, which is the correct configuration for production environments.

However, the content of the error page introduces three distinct problems in a SaaS context:

• Technology fingerprinting. The error page explicitly names ASP.NET and references server-side configuration artifacts (web.config, ). Security scanning tools such as Qualys, Nessus, and Burp Suite flag this as a technology disclosure finding under OWASP A05:2021 (Security Misconfiguration). The finding is typically rated Low or Informational, but it appears on every scan cycle and must be formally triaged, documented, and either remediated or accepted by the customer's security team. For organizations that undergo quarterly or annual penetration testing, this is a recurring item with no available remediation path.
• Misleading remediation guidance. The error page text instructs the viewer to create a tag within a web.config configuration file located in the root directory of the current web application. In Dynamics 365 Online, the server filesystem and IIS configuration are managed exclusively by Microsoft. Tenant administrators have no access to web.config, cannot modify mode settings, and cannot deploy custom error pages to the application root.
• The guidance on the page describes an action that is architecturally impossible in the D365 Online (SaaS) deployment model, generating confusion among end users and IT administrators, and results in support cases filed against a behavior that cannot be changed by the customer.
• Compliance overhead in regulated environments. Organizations in healthcare (e.g., HIPAA), financial services (e.g., MAS TRM, SOX), and government sectors are required to address all findings from security assessments, regardless of severity. Because no tenant-level control exists to suppress or customize this error page, security teams must carry the finding as a permanent accepted risk with documented justification, adding friction to vendor risk assessments and third-party audits where the customer is asked to demonstrate control over application error handling behavior.

Proposed solution:

A tiered approach that allows Microsoft to address the core issue with minimal effort while leaving room for more comprehensive improvements over time.

Tier 1: Update the default error page text (minimum viable fix). Remove all references to web.config, , and ASP.NET-specific terminology from the default runtime error page served to remote users in D365 Online environments. Replace the current boilerplate with a neutral message such as "An unexpected error occurred. Please try again or contact your administrator." This is a static text change to the error response template. It does not require new admin-facing UI, feature flags, or per-environment configuration. It eliminates the security finding at the source for all D365 Online tenants simultaneously.

Tier 2: Provide an administrative toggle in Power Platform Admin Center. Add a setting under Environment Settings > Features (or a comparable location in PPAC) that enables a "sanitized error page" mode. When enabled, the platform suppresses all server technology references from error responses served to end users while continuing to log full diagnostic details internally. This gives organizations an explicit, auditable control they can reference during security reviews and vendor assessments, and it aligns with how PPAC already exposes environment-level feature toggles for other platform behaviors.

Tier 3: Support custom error page content and branding. Allow tenant administrators to define custom error page text, branding, and contact information for their environments. This capability already has precedent within the Microsoft platform:

• Power Pages supports custom error pages through Site Actions > Disable custom errors, allowing portal administrators to control what end users see when errors occur.
• Power Platform DLP governance allows administrators to configure custom error messages with branded text and contact links that are shown when DLP policy violations are triggered.

Extending a similar pattern to model-driven apps would bring consistency to how the Power Platform handles error presentation across its surface areas.

Who would benefit from this change?

• Regulated industry customers (healthcare, finance, government) who undergo recurring security audits, penetration tests, and vendor risk assessments. These teams currently have no way to remediate or suppress the finding and must carry it as an accepted risk indefinitely.
• Security and compliance teams responsible for triaging, documenting, and justifying all findings from security scanning tools. Removing the technology disclosure from the error page eliminates the finding entirely and reduces the documentation burden per assessment cycle.
• All organizations using Dynamics 365 Online model-driven apps. The current error page surfaces server-side configuration concepts that are irrelevant to SaaS end users. A cleaner error message improves the end-user experience regardless of industry or compliance requirements.
• Microsoft support. This by-design behavior generates support cases from customers who encounter the error page and reasonably conclude that something is misconfigured in their environment. Updating the default text would reduce case volume for a known non-issue.

Business justification:

The core issue is a mismatch between the error page content and the D365 Online deployment model. The error page was designed for environments where administrators have access to web.config and can configure themselves. In D365 Online, that access does not exist. The page is telling users to do something they cannot do.

Microsoft has already implemented custom error handling capabilities in other parts of the platform (Power Pages custom error pages, Power Platform DLP custom error messages). The Tier 1 fix requires no new infrastructure, no new admin UI, and no per-tenant configuration. It is a static text update to the error response template that would resolve the finding for every D365 Online customer at once.