Skip to main content
Versa Networks

Integrate Versa SASE with Microsoft Defender

  1. Last updated
  2. Save as PDF

Versa-logo-release-icon.pngFor supported software information, click here.

This document describes the end-to-end architecture for integrating Microsoft Defender for Endpoint (MDE)—Microsoft's enterprise-grade Endpoint Detection & Response (EDR) platform—into Versa's Unified Risk Scoring (URS) framework within the SASE partner-services microservice.

The integration authenticates via OAuth 2.0 client credentials using an Azure App Registration, polls the Microsoft Security Center API for device health and vulnerability data, computes a per-device Zero Trust Access (ZTA) risk score using a configurable weighted model, stores the results, and publishes aggregated scores so that the Versa Management System (VMS) can enforce adaptive, risk-aware network policies in real time.

Defender requires an Azure App Registration with specific Microsoft Graph / Defender API application permissions, and uses the standard OAuth 2.0 client credentials flow to obtain short-lived bearer tokens automatically.

Prerequisites

To obtain the Tenant ID, Client ID, and Client Secret values required by the Versa Concerto EDR connector, you must register an application in Microsoft Entra ID (formerly Azure Active Directory). The application uses OAuth 2.0 client credentials to access the Microsoft Defender for Endpoint API without a user context.

You must have a Microsoft Entra role that allows creating applications in Azure, such as Application Administrator.

License Requirements

The Versa SASE Defender connector requires an Azure Active Directory App Registration in the customer's tenant with specific application permissions (not Delegated — the service runs as a background daemon, not on behalf of a signed-in user). A global administrator must grant admin consent before the integration can authenticate.

Access to the Microsoft Security Center APIs used by this integration requires the following license:

Note: Microsoft Defender for Endpoint has two license plans: Plan 1 and Plan 2. Versa recommends using Plan 2 for full integration. 

  • Microsoft Defender for Endpoint, Plan 2—Full Integration (Recommended):
    • Next-generation protection (Antivirus)
    • Attack surface reduction
    • Device inventory API ( /api/machines )
    • Endpoint Detection & Response (EDR)
    • Threat & Vulnerability Management (TVM)
    • Vulnerabilities API ( /api/machines/{id}/vulnerabilities )
    • Advanced hunting and threat Intelligence
    • Automated investigation and remediation
    • Full API access (device inventory, threat intelligence, TVM)

Note: Plan 2 unlocks all APIs used by this integration. All six scoring indicators (risk score, exposure level, AV status, health, onboarding, and vulnerabilities) are available.

The following table lists the APIs and features used by license plan 2. 

API / Feature  Plan 2

GET /api/machines—Device inventory

 Available
riskScore, healthStatus, defenderAvStatus fields Available
GET /api/machines/{id}/vulnerabilities—TVM CVE data Available
exposureLevel field (TVM exposure) Available
Advanced Hunting / KQL queries Available

Configure Microsoft Defender in Azure

  1. Create the App Registration by navigating to Home > Azure Active Directory > App registrations > New registration, then enter the required information.

    Azure-register-app-border.png
     
  2. Create a Client Secret (Certificates & secrets).
    1. Navigate to Home > Defender-PP > Certificates & secrets > Client secrets, then click + New client secret. The page initially shows an empty state with no secrets created.

      Azure-create-client-secret-border.png
       
    2. Click + New client secret. A panel slides in from the right. Enter a description and expiry period, then click Add.

      Azure-add-a new-client-secret-border.png

Caution: The secret value is displayed only once immediately after creation. Copy it to a vault before navigating away. It cannot be retrieved again. The secret ID is not used by Versa SASE. Only the value is used.

  1. Copy the Value. Once the secret is created the Value column shows the full string. This is the Client Secret to paste into the Versa SASE configuration screen.

    Azure-copy-the-value-border.png
     
  2. Add API Permissions.
    1. Navigate to Home > Defender-app > API permissions, then click Add a permission..
    2. Add permissions from two APIs: Microsoft Cloud App Security and WindowsDefenderATP.
    3. Select Application permissions (not Delegated) for each, then grant admin consent.

      Azure-configure-permissions- full-border.png

  3. Grant Admin Consent (Result). After the Global Administrator clicks Grant admin consent for Versa Networks and confirms in the dialog, both permission statuses change to Granted for Versa Networks. The connector is now authorized to authenticate.

    Azure-configured-permissions-border.png

Note: All 5 permissions must be granted as Application type—not Delegated. Microsoft Cloud App Security (discovery.manage, discovery.read) covers Cloud Discovery data access. WindowsDefenderATP (Machine.Read.All, Vulnerability.Read.All, Alert.Read.All) covers device inventory, TVM vulnerability data, and alert enrichment—all are required for the scoring model. Admin consent from a Global Administrator is mandatory before the OAuth2 token request will succeed.

Application vs Delegated: If you see Delegated permissions listed after adding, remove them and re-add them as Application type. Delegated permissions require an interactive user sign-in and will cause the background daemon connector to fail authentication.

Configure Microsoft Defender in Concerto

To configure Microsoft Defender in Concerto:

  1. From the Concerto Tenant home page, click Configure > Security Service Edge > Partner Integration > Endpoint Detection & Response in the left menu bar.

    Note that for Releases 12.1.1 and earlier, the Partner Integration Profile folder is located at Configure > Security Service Edge > Settings.

    EDR-left-nav-border-v3-border.png
  2. Select the Microsoft Defender tab, then enter information gathered from Azure for the following fields.

    EDR-Microsoft-Defender-v2-full-border-No-SentinelOne.png
     
    Field Description
    Enabled Click the slider to enable Microsoft Defender. 
    Tenant ID Enter the tenant ID generated by Microsoft Defender.
    Client ID Enter the client ID generated by Microsoft Defender.
    Client Secret Enter the client secret generated by Microsoft Defender.
    Poll Interval

    Enter the time, in minutes, between polling actions.

    Range: 10 through 1440 seconds

    Default: None
  3. Click Save.

After you save and publish the configuration, the following events occur:

Time After Publish Event
0 – 5 seconds Connector registered; OAuth2 token obtained; polling thread started; risk profiles loaded into memory.
5 seconds First device list pull from Microsoft Security Center API begins.
5 seconds + collection time Per-device vulnerability data fetched (up to 10 concurrent calls); ZTA risk scores calculated and stored per device.
~1 minute after collection Aggregated scores published to VMS via Kafka; adaptive network policies take effect.
Every Poll Interval thereafter Full cycle repeats automatically; token is refreshed transparently by the OAuth2 library.

Microsoft Security Center API Endpoints Called

Two registration paths exist: a Director push (bulk, all tenants) and a direct REST call (per tenant). Both converge into the same internal processing pipeline.

Method Microsoft API URL Purpose Scope Used

Post

https://login.microsoftonline.com/{tenantId}/oauth2/token

 Obtain OAuth2 Bearer token client credentials grant

Get

https://api.security.microsoft.com/api/machines

 Fetch all enrolled device records

Machine.Read.All

Get

https://api.security.microsoft.com/api/machines/{id}/vulnerabilities

 Fetch CVE list for a specific device (one call per device)

Vulnerability.Read.All

Risk Scoring Model

The ZTA risk score uses an implicit, configurable and weighted multi-factor model. All weights and thresholds are specified per tenant in the Director configuration. No code changes are required to tune the model for a customer's security posture. 

The risk score is calculated as follows: score  =  ( critical_score × CriticalRiskWeight )  +  ( operational_score × OperationalWeight )

Each sub-score is normalized to [0, 1] before weighting. Weights are integer percentages that must total 100 percent.

The risk scoring model uses the following critical risk indicators and operational health indicators.

Critical Risk Indicators Operational Health Indicators
Risk Score: Low Health Status: Inactive
Risk Score: Medium Health Status: ImpairedCommunication
Risk Score: High Inactive < 1 day
Exposure Level: Medium Inactive 1–3 days
Exposure Level: High Inactive 4–7 days
AV Status: Disabled Inactive 8–14 days
AV Status: Not Reporting Inactive > 14 days
Onboarding: Not Onboarded CVE count: Critical CVSS ( >= 9.0 )

The risk score is implicitly mapped to the following Versa risk bands:

  • Trustworthy (0–20)
  • Low Risk (21–40)
  • Moderate Risk (41–60)
  • Suspicious (61–80)
  • High Risk (81–100)

Software Release Information

Releases 12.2.1 and later support all content described in this article.