Skip to main content
The Azure integration connects your Azure tenant to Keldyn’s continuous-evidence engine. You create a read-only app registration in your own directory, assign three built-in Azure roles, and paste the Tenant ID, Client (App) ID, and Client Secret into Keldyn. Once connected, Keldyn reads subscription layout, role assignments, network security group rules, encryption and TLS settings, Microsoft Sentinel alerts and incidents, backup configuration, redundancy, and autoscale activity on a schedule, and turns them into live evidence for the related SOC 2 controls. For identity, MFA, access reviews, and PIM evidence, use the separate Microsoft Entra ID integration.
Integrations and automated evidence are typically managed by workspace admins. See Evidence & audits for how automated evidence fits alongside manual evidence.

​
What it’s used for

Keldyn uses the data it reads from Azure to keep infrastructure evidence current. Each refresh updates the evidence and freshness status shown on the integration’s Controls covered table. The integration contributes evidence to these SOC 2 controls:
Full coverage means the data is the artifact the control asks for. Partial coverage means the data usefully contributes but does not, on its own, replace everything the control requires. Keldyn labels partial coverage in the auto-generated evidence so it isn’t mistaken for complete coverage.
Segregated change environments is full only when the stored layout shows both production and a named non-production environment (from a name or an Environment / environment / Env tag). Resources Keldyn cannot classify default to production and are not treated as a fail. Network monitoring alerts applies where Microsoft Sentinel is onboarded; without it, that control is evidenced elsewhere and is not treated as a sync failure. System redundancy reflects configuration, not a tested failover. Auto-scaling stays unknown until Keldyn has seen at least one scale event in the activity log (Azure retains about 90 days).

​
Before you begin

1

Use an Azure subscription Owner or User Access Administrator

You need permission to create an app registration in Microsoft Entra ID and to assign roles on each subscription you want evidenced. Application Developer (or a Global / Application Administrator) can create the app; Owner or User Access Administrator can assign the roles.
2

Decide which subscriptions to include

Assign the read-only roles at subscription scope (or at a management group that contains those subscriptions). A role assigned only on a resource group is not enough — connect fails if the app can see no subscriptions.
3

Keldyn only ever reads

Use the three built-in read-only roles below. Keldyn never deploys, changes configuration, or writes to your tenant. Do not assign Owner or Contributor to the Keldyn app.

​
Set up the integration

Create a dedicated app registration in your Azure tenant, then paste its credentials into Keldyn. There is no OAuth redirect and no Keldyn-owned Azure account.
1

Create an app registration

In the Azure portal, open Microsoft Entra ID → App registrations → New registration.
  1. Name the app something stable, such as KeldynEvidence.
  2. Supported account types: Accounts in this organizational directory only (single tenant).
  3. Leave Redirect URI empty. This is a service principal (client credentials), not a signed-in user flow.
  4. Select Register.
From the app Overview, copy:Both values are GUIDs.
2

Create a client secret

On the same app, open Certificates & secrets → Client secrets → New client secret.
  1. Add a description such as keldyn-evidence.
  2. Choose an expiry (12 or 24 months is typical). Put a reminder on your calendar — an expired secret marks the connection Reauth required.
  3. Copy the secret Value immediately. Azure will not show it again.
That value is Client Secret in Keldyn. Do not upload a certificate; Keldyn only accepts a client secret.
3

Assign the three read-only roles

Repeat this for every subscription that should appear in evidence (or assign once at a management group that contains them).Open Subscriptions → the subscription → Access control (IAM) → Add → Add role assignment. Assign these built-in roles to the KeldynEvidence application (search Members by the app name, not a user):Connect probes the Azure subscriptions list. If the app can see none, Keldyn rejects the credentials and tells you to assign Reader at subscription scope.
4

Optional: resolve account IDs to names

Role assignments always store principal object IDs, which is enough for the access controls. To also show display names:
  1. On the app, open API permissions → Add a permission.
  2. Choose Microsoft Graph → Application permissions.
  3. Add Directory.Read.All.
  4. Select Grant admin consent for your tenant.
Without this permission, only the directory-name fetch shows Access required. Role assignments and every other source continue to refresh.
5

Connect in Keldyn

In the Keldyn web app, go to Integrations and select Azure. Paste Tenant ID, Client (App) ID, and Client Secret, then select Connect.Keldyn mints an Azure Resource Manager token with those credentials, confirms at least one subscription is visible, and stores the secret encrypted. The secret is never shown again — the form displays [redacted]. Use Update credentials when you rotate the secret (Tenant ID and Client ID stay the same).
6

Run the first sync

Select Sync now to pull evidence immediately, or wait for the scheduled refresh. Controls covered and Evidence sources then show what was collected and how fresh it is.
From the integration detail page, Controls covered shows whether Azure is actively feeding each control and whether the control is satisfied. Evidence sources shows each data fetch, the controls it covers, and its freshness.
Disconnecting in Keldyn does not delete the app registration or revoke the secret in Azure. Rotate or delete the client secret in the Azure portal when you no longer want the principal to have access.

​
What data Keldyn collects and why

Keldyn requests read-only access and never writes to your Azure tenant. It collects only the data below, and only to build control evidence.
Azure Activity Log retains about 90 days. Keldyn therefore accumulates scale events across refreshes rather than replacing them, so evidence can cover an audit period longer than Azure’s own retention window. The first sync after connecting shows only what Azure still holds.

​
Authentication

Keldyn authenticates as your Entra app registration using the OAuth 2.0 client-credentials flow (service principal). On each connect and each refresh it mints a short-lived Azure Resource Manager token (https://management.azure.com/.default) and, when resolving names, a Microsoft Graph token (https://graph.microsoft.com/.default). Those tokens are not stored — the client secret is the long-lived credential, stored encrypted. Disconnecting does not revoke the app in Azure.

​
Troubleshooting “Access required”

A control shows Access required when the service principal cannot read the matching data. Common causes include:
  • Reader is missing, or assigned only on a resource group. Connect itself fails if no subscriptions are visible.
  • Backup Reader is missing — backup policy, job, and restore-test sources fail; everything else continues.
  • Microsoft Sentinel Reader is missing — Sentinel sources fail with Access required. This is different from Sentinel not being in use: if no workspace has Security Insights onboarded, that source succeeds with empty records and Network monitoring alerts is evidenced elsewhere.
  • Graph Directory.Read.All is missing or admin consent was not granted — only the directory-name source fails. Role assignments still list object IDs.
  • The client secret expired or was rotated in Azure without Update credentials in Keldyn. The connection shows Reauth required.
Create a new secret on the same app, select Update credentials, paste the same Tenant ID and Client ID with the new secret, then run Sync now. Controls not affected by the missing role continue to refresh normally.

​
Keeping evidence current

Keldyn refreshes most Azure evidence automatically each day. Sentinel and autoscale/activity-log evidence refresh hourly so they stay fresher than the daily sources. Evidence that hasn’t refreshed within its expected cadence is marked stale, and failed pulls are marked failed so you can spot gaps. You can also trigger an immediate refresh at any time with Sync now.

​
Next steps

Evidence & audits

Learn how automated integration evidence works alongside manual evidence and audits.