Comparison

A client secret or a delegated sign-in for Intune automation

Most Intune export scripts run unattended, so they authenticate as an app: an app registration with application permissions and a client secret or certificate. TenuVault signs in as the admin instead, with no secret, and uses read-only app identities only for scheduled backups that must run without a user. This page compares the two models, because the choice decides what a stolen credential can do.

At a glance

Application permissions let an app use Microsoft Graph without a signed-in user, across the whole tenant. Intune roles and scope tags are assigned to users, so they do not narrow an app's application permissions.
A client secret is a password for the app. Microsoft's guidance for app registrations is not to use client secrets, and to use managed identities or certificates instead.
Delegated permissions act as the signed-in admin, so the effective access is the overlap of the app's permissions and the admin's Intune role, and MFA and Conditional Access apply.
TenuVault signs in as the admin through an app registration in your own tenant with no client secret, so MFA, Conditional Access and the admin's Intune role apply. Its app registration is a public client with delegated permissions only.
For scheduled backups that must run without a user, Pro and MSP add the Backup Reader, a read-only app registration with a certificate, and cloud backups, which use a managed identity in your own Azure Automation account. Neither can change Intune.
Conditional Access for workload identities can block an app that signs in with a secret or certificate, for example outside known locations. It needs Microsoft Entra Workload ID Premium and does not cover managed identities.

Side by side

An app registration with a client secret compared with TenuVault's sign-in
Question	Script with a client secret	TenuVault
Whose access the token carries	The app's, without a user	The signed-in admin's; read-only app identities only for scheduled backups on Pro and MSP
Credential to protect	The secret, wherever the script runs	None for the admin's sign-in; a certificate on each computer for the Backup Reader; for cloud backups, the Automation account and the recovery key in Key Vault
Intune role and scope tags	Do not apply	Apply to everything done with the admin's sign-in
MFA and Conditional Access	MFA does not apply; Conditional Access only through workload identity policies	Apply to the admin's sign-in; workload identity policies can cover the Backup Reader
Write access to Intune	Whatever the app was granted, often read and write so it can restore	Only with the admin's sign-in; the unattended identities are read-only
Name in the Intune audit log	The app	The admin, because every write uses the admin's sign-in
Runs with nobody signed in	Yes	Cloud backups yes; the Backup Reader while TenuVault runs on a computer that is on and signed in; the admin's sign-in until the session ends
Pipelines and command line	Yes	TenuVault has no command line or API, so it does not run inside a pipeline

How an app-only script authenticates

An unattended script uses an app registration with application permissions, such as DeviceManagementConfiguration.Read.All, granted by an administrator. It requests a token with the app's own credential, a client secret or a certificate, and no user is involved. That is what lets it run from a scheduled task, an Azure Automation account or a pipeline.

The price is a standing credential. Whoever holds the secret has the app's access until the secret expires or is removed, from any computer, with no MFA.

Microsoft Learn: Get access without a user

What a leaked secret can do

With read and write permissions, which a script needs to restore, anyone holding the secret can change or delete Intune configuration across the tenant. With read-only permissions they can still read all of it, including script contents and, per Microsoft's documentation, the plain-text values of encrypted OMA-URI settings.

That is why Microsoft's guidance is not to use client secrets for app registrations, and why the permissions of an unattended identity should be as narrow as the task allows.

Microsoft Learn: Security best practices for app registrations

How TenuVault handles sign-in

TenuVault's app registration has no secret and no certificate. Every token belongs to an admin who signed in, so the admin's MFA, Conditional Access and Intune role apply, and every change is recorded under the admin's name.

Scheduled backups also use that sign-in until a session control such as sign-in frequency ends it. For tenants where that stops backups at night, Pro and MSP add two read-only options. The Backup Reader is a separate app registration with a certificate whose private key stays on the TenuVault computer; TenuVault refuses it if its Graph token carries any permission beyond the read-only list. Cloud backups run in your own Azure Automation account with a managed identity, so there is no secret or certificate to manage; protect who can edit the Automation account and read its Key Vault. In Azure Storage, both write with the TenuVault Backup Writer role, which cannot delete.

What TenuVault does not do

TenuVault has no command line or API, so it does not run inside a pipeline.
Restores and every other change always need an admin's sign-in; nothing writes to Intune unattended.
The Backup Reader certificate is a credential that can read all Intune configuration. Treat it like an admin credential and renew it yearly.
A managed identity cannot be restricted by Conditional Access; its controls are its read-only roles and its sign-in log.

When you do not need TenuVault

An app-only script can be the right model when:

Your configuration is managed as code in a pipeline, which needs an unattended identity.
The script already uses a certificate or a managed identity with read-only permissions, and the credential is stored in a key vault.
You restrict the app with Conditional Access for workload identities and review its sign-ins.

Making an app-only script safer

Give export scripts read-only permissions, and use a separate identity for anything that writes.
Prefer a managed identity where the script runs in Azure, and a certificate over a client secret elsewhere.
Give secrets and certificates a short lifetime and a named owner who rotates them.
Review the app's sign-ins and remove credentials nobody uses.

Microsoft Learn: Conditional Access for workload identities

Read the technical guides

Product scope reviewed 4 November 2026. Check your installed release and the current plan table before using a workflow.

Frequently asked questions

Should an Intune backup script use a client secret?

Prefer a managed identity when the script runs in Azure, and a certificate elsewhere. Microsoft's guidance for app registrations is not to use client secrets. Give an export script read-only permissions, so a leaked credential cannot change or delete policies.

Do application permissions respect Intune scope tags?

No. An app with application permissions can use them across the tenant. Intune roles and scope tags are assigned to users, so they do not narrow an app's application permissions.

Does Conditional Access apply to an app that signs in with a client secret?

Only through Conditional Access for workload identities, which needs Microsoft Entra Workload ID Premium and covers single-tenant service principals. Policies for users, including MFA, do not apply to app-only sign-ins, and managed identities are not covered.

Does TenuVault need a client secret?

No. TenuVault signs in as the admin through a public client app registration with delegated permissions and no secret. The optional Backup Reader for scheduled backups uses a certificate and read-only permissions, never a secret.