🛡️ Azure Role-assigned Service Principal uses client secrets🟢⚪

• Contextual name: 🛡️ Role-assigned Service Principal uses client secrets🟢⚪
• ID: /ce/ca/azure/microsoft-entra-id/role-assigned-service-principals-client-secrets
• Tags:
  • ⚪ Impossible policy
  • 🟢 Policy with categories
  • 🟢 Policy with type
• Policy Type: COMPLIANCE_POLICY
• Policy Categories: SECURITY

Stats

not available

Description

Open File

Description

A service principal that holds an Azure role assignment signs in with a client secret, a certificate, or a federated credential, unless it is a managed identity, which has no readable credential. Prerequisites: Move each workload that signs in with a client secret to a managed identity, a federated credential, or a certificate, and confirm it works before removing the secret.

Rationale

A client secret is a long-lived string that the workload sends to Microsoft Entra ID, so anyone who copies it from code, configuration, or a pipeline can sign in as the application from anywhere. The holder inherits every Azure role the service principal holds until the secret expires or is removed, and the sign-ins look like the workload's own.

Audit

This requirement needs manual assessment. Service-principal password credentials and their absence are not collected; certificate inventory does not establish absence of client secrets.

Remediation

Open File

Remediation

A service principal that holds an Azure role assignment signs in with a client secret, a certificate, or a federated credential, unless it is a managed identity, which has no readable credential. Prerequisites: Move each workload that signs in with a client secret to a managed identity, a federated credential, or a certificate, and confirm it works before removing the secret.

After verifying the replacement authentication method, remove the client secrets from each role-assigned application and service principal. For application credentials, use Microsoft Entra ID > App registrations > Certificates & secrets > Client secrets. Review credentials held directly on the service principal through Azure CLI or PowerShell as well. Confirm that dependent workloads continue to authenticate successfully.

Automated assessment is unavailable: Service-principal password credentials and their absence are not collected; certificate inventory does not establish absence of client secrets.

policy.yaml

Open File

Linked Framework Sections

Section	Sub Sections	Internal Rules	Policies	Flags	Compliance
💼 CIS Azure v7.0.0 → 💼 5.11 Ensure Service Principals Holding Azure Role Assignments Do Not Use Client Secrets (Automated)			1		no data
💼 Cloudaware Framework → 💼 Credential Lifecycle Management			39		no data