Microsoft Defender for Identity

You can connect Incode identity verification to Microsoft Sentinel so that when Defender for Identity raises a suspicious activity incident, your security team can send the flagged user a biometric verification link. The result is posted back to Sentinel automatically, giving your team the identity confirmation they need to resolve or escalate the incident.

This integration is well-suited for Identity Threat Detection and Response (ITDR) workflows where you need to distinguish real security incidents from false positives caused by legitimate employees travelling, working from new devices, or logging in at unusual hours.

Prerequisites

Before you begin, ensure you have:

  • An active Azure subscription with permissions to create Logic Apps and assign roles within a resource group
  • A Microsoft Sentinel workspace
  • Access to the Integrations page in Dashboard. Contact your Incode Representative if you do not see the Integrations page.
  • Users to be verified must exist as directory records within the Incode integration before verification requests can succeed

How It Works

The integration runs on two Azure Logic Apps deployed in your Azure environment.

The first Logic App is a Sentinel automation playbook. When a Sentinel incident is created, the playbook calls the Incode API to generate a unique verification link for the flagged user and delivers it to your security team to send on.

The second Logic App is a webhook receiver. When the user completes their biometric check, Incode sends the result to this receiver. The receiver reads the result and updates the Sentinel incident — closing it as a false positive if verification succeeded, or escalating it to High severity if verification failed.

Both Logic Apps use a managed identity to authenticate against Azure Key Vault (for Incode credentials) and Microsoft Sentinel (to update incidents). No credentials are hardcoded.

Set Up Guide

Step 1: Create an Integration in Incode Omni

  1. Log in to Dashboard.
  2. In the left navigation, click Integrations.
  3. Click New integration.
  4. From the Custom tab, click API, then click Continue.
  5. Enter a Name for the integration (for example, Microsoft Defender).
  6. Click Save.
  7. Open the integration card and note the Integration ID. This is required for future steps.

Step 2: Collect Your Incode Credentials

You will store the following values securely in Azure Key Vault. See Find Integration Details for where to locate each one in the Omni Dashboard.

  • Client ID: Your OAuth client identifier
  • Client Secret: Generate a new one if you do not have one already
  • API Key: Obtain from your Incode account team if you do not have one
  • Integration ID: The value from Step 1
  • Auth server URL: https://auth.demo.incode.com (demo) or https://auth.incode.com (production)
  • API base URL: https://demo-api.incodesmile.com (demo) or https://saas-api.incodesmile.com (production)

Step 3: Deploy the Azure Resources

Incode provides both Logic Apps as ready-to-deploy ARM templates. Click the Deploy to Azure button in the Incode GitHub repository to deploy both Logic Apps and an Azure Key Vault into a resource group in your Azure subscription in one step.

📘

Note: If you do not have access to the ARM templates yet, contact your Incode account team.

Once deployed, store the following secrets in Key Vault using the exact secret names listed:

Secret nameValue
incode-client-idYour Incode OAuth Client ID
incode-client-secretYour Incode OAuth Client Secret
incode-api-keyYour Incode API Key
incode-integration-referenceYour Integration ID from Step 1
incode-auth-urlAuth server URL from Step 2
incode-api-base-urlAPI base URL from Step 2
📘

Note on storing secrets with special characters: Use the Azure Cloud Shell Python approach to avoid special characters being misread by bash:

python3 -c "

import subprocess

[subprocess.run](http://subprocess.run)(['az', 'keyvault', 'secret', 'set',

'--vault-name', 'YOUR_KEYVAULT_NAME',

'--name', 'incode-client-secret',

'--value', 'YOUR_SECRET_VALUE_HERE'])

"

`

After storing all secrets, grant the Logic App managed identity Get and List permissions on Key Vault secrets.

Step 4: Assign the Sentinel Responder Role

The Logic Apps use a managed identity to update incidents in Sentinel. Grant this identity the Microsoft Sentinel Responder role from Azure Cloud Shell:

az role assignment create \
  --assignee YOUR_MANAGED_IDENTITY_PRINCIPAL_ID \
  --role "Microsoft Sentinel Responder" \
  --scope /subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/YOUR_RESOURCE_GROUP
📘

Note: Role assignments can take up to 10 minutes to propagate. Wait before testing.

Step 5: Configure Webhooks in Dashboard

The webhook receiver Logic App needs to receive session results from Incode when a user completes verification.

  1. In Dashboard, from the left navigation, click Configuration.
  2. Switch to the Webhooks tab.
  3. Find the Flow or Workflow associated with your integration.
  4. Add the webhook receiver Logic App URL as the endpoint for the SESSION_SUCCEEDED and SESSION_FAILED events.

To find the receiver Logic App URL, open the Logic App in the Azure portal, go to Overview, and copy the Workflow URL.

📘

Note: Incode requires a webhook authentication secret to be configured before session webhooks are delivered. Contact your Incode account team to confirm the required format for your environment.

Step 6: Connect Sentinel to the Playbook

  1. In Microsoft Sentinel, create a new automation rule.
  2. Set the trigger to When an incident is created.
  3. Configure conditions to match the incidents you want to trigger verification for (for example, by severity or incident type).
  4. Set the action to Run playbook and select the playbook Logic App.
  5. Save the automation rule.

Step 7: Test the Integration

Verify the end-to-end flow from Azure Cloud Shell:

curl -s -X POST \
  "YOUR_PLAYBOOK_TRIGGER_URL" \
  -H "Content-Type: application/json" \
  -d '{"incidentId":"TEST-001","severity":"Medium","userEmail":"[email protected]"}' \
  | python3 -m json.tool

A successful response includes a verificationUrl field and a status of verification_initiated. Open the URL to complete a test biometric check, then confirm the Sentinel incident was updated as expected.

Important Technical Notes

The api-version: 1.0 header is required. Every call to the Incode B2B onboarding endpoint (POST /omni/b2b/onboarding/request-new) must include the header api-version: 1.0. Without it the API returns HTTP 406 with no explanation.

externalCustomerId is required for incident correlation. Pass the Sentinel incident ID as externalCustomerId in every B2B onboarding request. Incode echoes this value back in the session webhook payload. Without it, the webhook receiver has no way to identify which incident to update.

Users must exist in the Incode directory before verification. If the loginHint (user email) does not match any record in the integration directory, the API returns error 5504: Employee by login factor cannot be found. Add the user to the integration directory in the Omni Dashboard before retrying.

Troubleshooting

Playbook fails at OAuth token step with HTTP 401.

The Client ID or Client Secret in Key Vault is wrong or has been rotated. Verify credentials manually from Cloud Shell:

curl -s -X POST "{auth_url}/oauth2/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials&scope=openid&client_id={client_id}&client_secret={client_secret}"

Playbook fails at B2B onboarding step with HTTP 406.

The api-version: 1.0 header is missing from the HTTP action in the Logic App.

Playbook fails with error 5504.

The user email passed as loginHint does not exist in the Incode integration directory. Add the user in the Omni Dashboard and retry.

Webhook receiver never fires after verification completes.

Three possible causes: session webhooks are not configured in Omni for the correct Flow or Workflow; the webhook auth secret is missing or incorrectly configured; or the webhook is configured at the wrong level (session webhooks are scoped to individual Flows or Workflows, not globally).

Webhook receiver fires but Sentinel update fails with HTTP 403.

The managed identity does not have the Microsoft Sentinel Responder role, or the role assignment has not yet propagated. Wait up to 10 minutes and retry.

Sentinel incident is not updated after verification completes.

The externalCustomerId in the webhook payload does not match a valid Sentinel incident ID. Confirm that the incident ID is being correctly passed in the original B2B onboarding request.

Supported Environments

EnvironmentAuth server URLAPI base URL
Demohttps://auth.demo.incode.comhttps://demo-api.incodesmile.com
Productionhttps://auth.incode.comhttps://saas-api.incodesmile.com