When setting up Security Copilot why is it creating 2 enterprise applications?

Souders, Justin 25 Reputation points
2025-03-06T15:45:09.8+00:00

We setup security copilot in our Azure environment following the setup instructions listed here. Everything appears to be setup correctly, but I noticed that there were 2 enterprise applications created during this process with the same name (Security Copilot). The only difference I saw between the 2 was in the identifierUri attribute. One had its value set to "{object id}, https://api.medeina.defender.microsoft.com, https://api.securitycopilot.microsoft.com" and the other had "{object id}, https://api.medeina.defender.microsoft.com". Is this by design or is this a bug in the process?

Microsoft Copilot
Microsoft Copilot
Microsoft terminology for a universal copilot interface.
649 questions
{count} votes

Accepted answer
  1. Jose Benjamin Solis Nolasco 631 Reputation points
    2025-03-06T18:12:21.9333333+00:00

    Hello @Souders, Justin

    This behavior is by design and not a bug. When setting up Security Copilot, two enterprise applications are created to separate and manage the different integration endpoints required by the solution. Here’s what’s happening:

    Dual Endpoint Integration: One of the enterprise applications is registered with both identifier URIs—https://api.medeina.defender.microsoft.com and https://api.securitycopilot.microsoft.com. This registration is used to access the full set of Security Copilot functionality that relies on both the Defender API backend and Security Copilot’s own API.

    Legacy/Segmented Role: The second enterprise application, which only includes the Defender API endpoint (https://api.medeina.defender.microsoft.com), is maintained for backward compatibility and to support scenarios or components that only need to interact with Microsoft Defender’s API. It ensures that legacy integrations or isolated parts of the solution that only require that one endpoint continue to work without disruption.

    Why This Matters:

    • Granular Permission Management: By splitting the applications, permissions, consent, and access control can be managed separately for each set of endpoints. This separation means that if the API for Security Copilot evolves or requires additional security considerations, those changes can be handled independently from the Defender integration.
    • Modular Architecture: This approach follows a modular design pattern, offering the flexibility to update one component without forcing changes across the entire solution.
    • Future Enhancements: It also provides room for future enhancements or changes in the API endpoints without impacting the overall user experience.This behavior is by design and not a bug. When setting up Security Copilot, two enterprise applications are created to separate and manage the different integration endpoints required by the solution. Here’s what’s happening:
      1. Dual Endpoint Integration: One of the enterprise applications is registered with both identifier URIs—https://api.medeina.defender.microsoft.com and https://api.securitycopilot.microsoft.com. This registration is used to access the full set of Security Copilot functionality that relies on both the Defender API backend and Security Copilot’s own API.
      2. Legacy/Segmented Role: The second enterprise application, which only includes the Defender API endpoint (https://api.medeina.defender.microsoft.com), is maintained for backward compatibility and to support scenarios or components that only need to interact with Microsoft Defender’s API. It ensures that legacy integrations or isolated parts of the solution that only require that one endpoint continue to work without disruption.
      Why This Matters:
      • Granular Permission Management: By splitting the applications, permissions, consent, and access control can be managed separately for each set of endpoints. This separation means that if the API for Security Copilot evolves or requires additional security considerations, those changes can be handled independently from the Defender integration.
      • Modular Architecture: This approach follows a modular design pattern, offering the flexibility to update one component without forcing changes across the entire solution.
      • Future Enhancements: It also provides room for future enhancements or changes in the API endpoints without impacting the overall user experience.

    😊 If my answer helped you resolve your issue, please consider marking it as the correct answer. This helps others in the community find solutions more easily. Thanks!

    1 person found this answer helpful.
    0 comments No comments

0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.