[New Check]: Federated identity credentials on app registrations have no audit coverage #12747

Existing check search

• I have searched existing issues, Prowler Hub, and the public roadmap, and this check does not already exist.

Provider

Microsoft 365

New provider name

No response

Service or product area

entra

Suggested check name

entra_app_registration_federated_credential_on_privileged_app

Context and goal

• Security condition to validate: application registrations that hold federatedIdentityCredentials are currently invisible to every Entra check. Neither prowler/providers/m365/services/entra/ nor prowler/providers/azure/services/entra/ reads that collection today, while the sibling credential types are covered (entra_app_registration_client_secret_unused on m365, entra_app_registration_credential_not_expired on azure).
• Why it matters: [New Check]: Application registrations should not use password credentials (client secrets) #11064's rationale for the client-secrets work recommends certificates, managed identities and federated identity credentials as the migration targets - so as tenants follow that guidance, the credential type they move to is the one the scan says nothing about. A federated identity credential grants standing token exchange to an external issuer/subject pair and has no expiry, so it sits outside the existing expiry- and unused-secret-shaped checks by construction. The highest-signal case is an FIC on an application that also holds privileged permissions: an external CI system (GitHub Actions, GitLab CI, etc.) can then mint tokens that act with those permissions, and the trust boundary lives entirely in the external provider's account/repo namespace. A related concern for a follow-up rather than this first check: for public CI issuers the subject match is exact-string, and a deleted external org or repository name can later be re-registered by an unrelated party.
• Resource involved: Microsoft Entra application registrations (/applications) and their federatedIdentityCredentials collection.

Expected behavior

• Resource or scope to evaluate: all application objects in the tenant, expanding federatedIdentityCredentials (via $expand on the existing applications listing, or the per-application GET /applications/{id}/federatedIdentityCredentials endpoint), joined with the application's permission grants that the existing privileged-permissions check already models.
• PASS when: an application either has no federated identity credentials, or has them while holding no privileged permissions.
• FAIL when: an application holds at least one federated identity credential AND privileged permissions. The finding should report appId, displayName, and each FIC's name, issuer and subject, so operators can see exactly which external identity can act with the privileged rights.
• MANUAL when: not applicable.
• Exclusions / edge cases: this is deliberately not a check against having FICs in general - they are the recommended replacement for client secrets, and flagging their mere presence would penalize the practice [New Check]: Application registrations should not use password credentials (client secrets) #11064 encourages. The proposal scopes FAIL to the privileged-app combination only.

References

• Microsoft Graph v1.0 - federatedIdentityCredential resource (List/Get methods, issuer/subject/audiences properties): https://learn.microsoft.com/en-us/graph/api/resources/federatedidentitycredential?view=graph-rest-1.0
• Microsoft Entra Workload ID - workload identity federation: https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation
• Prior art in this repo: [New Check]: Application registrations should not use password credentials (client secrets) #11064 (client-secrets state check and its recommendation of FICs as a migration target)

Suggested severity

Medium

Additional implementation notes

• Existing patterns to follow: entra_app_registration_no_unused_privileged_permissions already iterates application registrations and models privileged permissions; entra_app_registration_client_secret_unused already extends the applications listing with a credential collection. This check is the composition of the two patterns.
• Permissions / scopes: the FIC list should be covered by the existing application-read baseline, though that is worth confirming against the Graph List federatedIdentityCredentials permissions table rather than taken from here.
• Microsoft Graph v1.0 only; no PowerShell needed.

Is there a reason federated identity credentials were left out of scope so far - or would a first check shaped like the two existing credential checks fit the service model?