A cloud-based identity and access management service for securing user authentication and resource access
With application permissions (client credentials flow), Microsoft Entra ID authenticates the application itself, not a user. As a result, Entra sign-in logs record the service principal, application ID, tenant, IP address, and related authentication details, but there is no user identity because no user participated in the authentication. Therefore, Entra logs cannot tell you which person launched the application.
To identify the human operator, you must rely on controls outside Entra ID. If the application runs on managed Windows devices, you can correlate Entra sign-in logs (timestamp, application ID, IP address, and device) with Windows Security logs, process creation events (Event ID 4688), Microsoft Defender for Endpoint telemetry, or Microsoft Sentinel if these logs are collected. This should help identify the signed-in Windows user who started the process.
A better approach might be to avoid shared client secrets whenever possible. Use managed identities for Azure-hosted workloads or workload identity federation instead of client secrets. For applications running on user workstations, consider using delegated permissions if the scenario permits, or modify the application to record the signed-in Windows user in its own audit logs. If application permissions are indeed required, you should maintain application-level audit logs to identify the person who initiated the application.
If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.
hth
Marcin