diff --git a/dotnet/xml/Microsoft.Identity.Client.Extensibility/ICustomWebUi.xml b/dotnet/xml/Microsoft.Identity.Client.Extensibility/ICustomWebUi.xml
index 0cebf2b57..312100737 100644
--- a/dotnet/xml/Microsoft.Identity.Client.Extensibility/ICustomWebUi.xml
+++ b/dotnet/xml/Microsoft.Identity.Client.Extensibility/ICustomWebUi.xml
@@ -55,13 +55,24 @@
   </AssemblyInfo>
   <Interfaces />
   <Docs>
+    <remarks>
+      <format type="text/markdown"><![CDATA[
+> [!CAUTION]
+> **ICustomWebUi is not recommended for production use due to security risks and current service limitations, and is on a deprecation path.**
+>
+> This pattern introduces security risks and is not supported by Entra ID cloud services. Using native client redirect URIs (like `https://login.microsoftonline.com/common/oauth2/nativeclient`) with custom web UI implementations typically requires users to manually copy the authorization code from the URL—an anti-pattern most commonly seen with the `nativeclient` URI. This pattern will not work in most configurations and poses security risks.
+>
+> - **Recommended Alternatives**: 
+>   - **Use [Broker authentication (WAM)](https://learn.microsoft.com/entra/msal/dotnet/acquiring-tokens/desktop-mobile/wam)** for Windows 10+ applications - provides the best security and user experience
+>   - **Use embedded browser flow** as described in [Using web browsers](https://learn.microsoft.com/entra/msal/dotnet/acquiring-tokens/using-web-browsers)
+]]></format>
+            </remarks>
     <summary>
             Interface that an MSAL.NET extender can implement to provide their own web UI in public client applications
             to sign-in user and have them consented part of the Authorization code flow.
             MSAL.NET provides an embedded web view for Windows and Mac, but there are other scenarios not yet supported.
             This extensibility point enables them to provide such UI in a secure way
             </summary>
-    <remarks>To be added.</remarks>
   </Docs>
   <Members>
     <Member MemberName="AcquireAuthorizationCodeAsync">
diff --git a/msal-dotnet-articles/advanced/extensibility-points.md b/msal-dotnet-articles/advanced/extensibility-points.md
index 1cfb2bf1e..7ad873457 100644
--- a/msal-dotnet-articles/advanced/extensibility-points.md
+++ b/msal-dotnet-articles/advanced/extensibility-points.md
@@ -64,6 +64,15 @@ Details [here](/dotnet/api/microsoft.identity.client.abstractacquiretokenparamet
 
 ## Desktop / Mobile Apps - ICustomWebUi
 
-Allows desktop and mobile apps to use their own browser instead of the embedded / system browsers provided by MSAL.
+> [!CAUTION]
+> **ICustomWebUi is not recommended for production use due to security risks and current service limitations, and is on a deprecation path.**
+>
+> This pattern introduces security risks and is not supported by Entra ID cloud services. Using native client redirect URIs (like `https://login.microsoftonline.com/common/oauth2/nativeclient`) with custom web UI implementations typically requires users to manually copy the authorization code from the URL—an anti-pattern most commonly seen with the `nativeclient` URI. This pattern will not work in most configurations and poses security risks.
+>
+> - **Recommended Alternatives**: 
+>   - **Use [Broker authentication (WAM)](../acquiring-tokens/desktop-mobile/wam.md)** for Windows 10+ applications - provides the best security and user experience
+>   - **Use embedded browser flow** as described in [Using web browsers](../acquiring-tokens/using-web-browsers.md)
+
+While ICustomWebUi allows desktop and mobile apps to use their own browser instead of the embedded / system browsers provided by MSAL, it should only be used for testing or legacy scenarios where migration is not yet possible.
 
 Details [here](/dotnet/api/microsoft.identity.client.extensibility.icustomwebui?view=azure-dotnet)