Agent Foskett Case File • Microsoft Entra ID • App Registration • Service Principal • Workload Identity • Certificate Authentication
The App Registration Had No Secret — So How Was It Authenticating?
The application was successfully authenticating to Microsoft Entra ID.
There was just one problem.
The app registration had no client secret.
No obvious password-style credential explained the successful token requests.
Agent Foskett stopped treating “no secret” as “no credential” and followed the workload identity evidence instead.
What identity was actually signing in — and what credential was it presenting?
No Secret. Successful Authentication.
A client secret is only one way an application can authenticate. The investigation had to identify the application, its service principal, its configured credentials and the workload sign-ins that showed what was happening.
✓ Identify the workload identity
✓ Inspect configured credentials
✓ Correlate the sign-in evidence
The finding looked impossible
A security review identified repeated successful non-interactive authentication associated with an application.
The first check seemed reassuring: the app registration did not have a client secret configured.
But the authentication evidence was real.
That meant the absence of a secret was not the end of the investigation. It was the beginning.
Applications can authenticate with credentials other than client secrets.
The first check seemed reassuring: the app registration did not have a client secret configured.
But the authentication evidence was real.
That meant the absence of a secret was not the end of the investigation. It was the beginning.
Applications can authenticate with credentials other than client secrets.
Application object and service principal are not the same thing
Agent Foskett first separated two objects that are often spoken about as though they are interchangeable.
App registrationThe application object defines the application in its home tenant, including identifiers and configured credentials.
Service principalThe service principal is the application's identity in a tenant and is the object used for access and authorization there.
Workload sign-inThe sign-in evidence shows the service principal or managed identity attempting to obtain access as a workload identity.
Start with the workload sign-ins
Where Microsoft Entra service principal sign-in logs are available in Microsoft Sentinel, the
AADServicePrincipalSignInLogs table can provide the timeline Agent Foskett needed. He started with the application identifier rather than guessing which credential was involved.- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
let AppId = "11111111-2222-3333-4444-555555555555";
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where AppId =~ AppId
| project TimeGenerated,
AppDisplayName,
AppId,
ServicePrincipalId,
ResourceDisplayName,
IPAddress,
ResultType,
ResultDescription
| order by TimeGenerated descThe successful events changed the investigation
The sign-in history showed successful activity for the service principal.
That ruled out the simple explanation that the application was merely configured but unused.
Agent Foskett now had an application ID, a service principal ID, timestamps, resources and source context to investigate.
The question was no longer whether the application authenticated. The question was how.
That ruled out the simple explanation that the application was merely configured but unused.
Agent Foskett now had an application ID, a service principal ID, timestamps, resources and source context to investigate.
The question was no longer whether the application authenticated. The question was how.
Investigation principle: Configuration tells you what could happen. Sign-in telemetry tells you what did happen.
No client secret does not mean no credential
Microsoft Entra applications can use certificate credentials as an alternative to client secrets. A certificate-based client assertion allows the application to prove possession of the private key corresponding to a public certificate configured for the application.
The private key itself is not stored in the app registration. The application or its hosting platform must possess it.
That distinction explained why looking only for a secret produced the wrong conclusion.
The private key itself is not stored in the app registration. The application or its hosting platform must possess it.
That distinction explained why looking only for a secret produced the wrong conclusion.
Inspect the app registration's credentials
Agent Foskett checked the application's configured credentials. In Microsoft Graph, application objects expose password credentials and key credentials separately. A missing password credential does not make the key credential collection irrelevant.
For an authorised investigation, Microsoft Graph PowerShell can be used to retrieve the application object and inspect its credential metadata.
For an authorised investigation, Microsoft Graph PowerShell can be used to retrieve the application object and inspect its credential metadata.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
$app = Get-MgApplication -Filter "appId eq '11111111-2222-3333-4444-555555555555'"
$app | Select-Object DisplayName, AppId, Id
$app.PasswordCredentials |
Select-Object DisplayName, KeyId, StartDateTime, EndDateTime
$app.KeyCredentials |
Select-Object DisplayName, KeyId, Type, Usage,
StartDateTime, EndDateTimeThere it was: a key credential
The application had no password credential — but it did have a key credential associated with certificate-based authentication.
That was the missing piece.
The visible public credential metadata did not reveal the private key, and it did not by itself prove which machine held that private key. But it established that the application had another valid authentication mechanism configured.
The app had no secret. It did not have no credential.
That was the missing piece.
The visible public credential metadata did not reveal the private key, and it did not by itself prove which machine held that private key. But it established that the application had another valid authentication mechanism configured.
The app had no secret. It did not have no credential.
Now investigate the certificate timeline
The credential's start and expiry dates mattered. Agent Foskett compared them with the first and last successful workload sign-ins.
If successful authentications occurred while the certificate credential was valid, the timelines were consistent with certificate-based authentication. That correlation strengthened the investigation, but Agent Foskett still avoided claiming more than the available telemetry proved.
If successful authentications occurred while the certificate credential was valid, the timelines were consistent with certificate-based authentication. That correlation strengthened the investigation, but Agent Foskett still avoided claiming more than the available telemetry proved.
Credential createdWhen did the certificate/key credential become available to the application?
Successful sign-insWhen did the service principal successfully authenticate and to which resources?
Credential expiryWas the key credential valid during the observed authentication window?
Who added the credential?
A certificate can be completely legitimate. It can also become an important persistence mechanism if an attacker with sufficient privileges adds a credential to an application they control or compromise.
Agent Foskett therefore moved from sign-in evidence to change history.
The investigation searched Microsoft Entra audit logs for updates to the application and service principal around the time the credential appeared.
Agent Foskett therefore moved from sign-in evidence to change history.
The investigation searched Microsoft Entra audit logs for updates to the application and service principal around the time the credential appeared.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
AuditLogs
| where TimeGenerated > ago(90d)
| where Category =~ "ApplicationManagement"
| where OperationName has_any (
"application",
"service principal")
| mv-expand TargetResources
| where tostring(TargetResources.displayName)
=~ "Finance Automation"
| project TimeGenerated,
OperationName,
Result,
InitiatedBy,
TargetResources
| order by TimeGenerated ascThe audit event needed inspection, not assumptions
Agent Foskett inspected the relevant
He did not assume that every application-management event meant a certificate had been added. Operation names and modified properties must be examined in the tenant's actual audit data.
The change record provided context for the credential. The sign-in record provided context for its use.
AuditLogs records and their modified properties to determine what changed, who initiated the change and whether the activity matched an approved deployment.He did not assume that every application-management event meant a certificate had been added. Operation names and modified properties must be examined in the tenant's actual audit data.
The change record provided context for the credential. The sign-in record provided context for its use.
What about managed identities?
Agent Foskett also considered another important possibility: not every workload authentication uses a secret or a certificate manually configured on an ordinary app registration.
Azure managed identities are service principals whose credentials are managed by the platform. If the identity under investigation were a managed identity, the investigation path would be different.
That is why the analyst must identify the workload identity type before deciding what credential should exist.
Azure managed identities are service principals whose credentials are managed by the platform. If the identity under investigation were a managed identity, the investigation path would be different.
That is why the analyst must identify the workload identity type before deciding what credential should exist.
Investigation principle: “No secret” is a clue, not a conclusion.
Scope the service principal's activity
Once the identity was understood, Agent Foskett looked beyond a single successful sign-in. He summarised the resources, source IP addresses and result patterns associated with the service principal.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
let ServicePrincipalId =
"aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee";
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ServicePrincipalId =~ ServicePrincipalId
| summarize SignIns=count(),
FirstSeen=min(TimeGenerated),
LastSeen=max(TimeGenerated)
by ResourceDisplayName,
IPAddress,
ResultType
| order by SignIns descPermissions answer a different question
Authentication established that the workload identity could prove who it was. Authorization determined what it could do after authentication.
Agent Foskett therefore reviewed the service principal's assigned permissions and application role assignments separately.
A certificate does not grant Microsoft Graph or resource permissions by itself. It is an authentication credential. The service principal's permissions determine the potential impact of successful authentication.
Credential + identity + permissions + activity = the investigation context.
Agent Foskett therefore reviewed the service principal's assigned permissions and application role assignments separately.
A certificate does not grant Microsoft Graph or resource permissions by itself. It is an authentication credential. The service principal's permissions determine the potential impact of successful authentication.
Credential + identity + permissions + activity = the investigation context.
Build the workload identity timeline
The evidence became clearer when Agent Foskett stopped viewing the app registration as a static configuration screen and reconstructed it as a timeline.
Application establishedIdentify the application object and corresponding service principal.
Credential configuredDetermine what password or key credentials exist and when they became valid.
Workload authenticatesCorrelate successful service principal sign-ins with the credential window.
Resources accessedDetermine which resources received the workload identity's authentication attempts.
Permissions reviewedEstablish what the service principal was authorised to do.
Change history checkedDetermine whether credential and application changes were expected.
What Agent Foskett checked
App IDWhich application generated the workload sign-ins?
Service principalWhich tenant identity represented the application?
Password credentialsWere any client secrets configured?
Key credentialsWas certificate-based authentication available?
Audit historyWho changed the application and when?
Workload activityWhen, where and against which resources did the identity authenticate?
What the evidence can and cannot prove
A configured certificate credential demonstrates that certificate-based authentication is available to the application during its validity period. Successful service principal sign-ins demonstrate workload authentication activity.
Correlating those facts can strongly support the investigation, but analysts should not invent a private-key location or credential-use detail that their telemetry does not actually expose.
Likewise, a successful workload sign-in does not by itself prove malicious activity. The application owner, change history, source context, permissions, deployment design and expected behaviour all matter.
Follow the evidence far enough to explain the authentication — but not farther than the evidence allows.
Correlating those facts can strongly support the investigation, but analysts should not invent a private-key location or credential-use detail that their telemetry does not actually expose.
Likewise, a successful workload sign-in does not by itself prove malicious activity. The application owner, change history, source context, permissions, deployment design and expected behaviour all matter.
Follow the evidence far enough to explain the authentication — but not farther than the evidence allows.
The lesson
The app registration had no client secret.
At first glance, that seemed inconsistent with the successful authentication events.
It wasn't.
Agent Foskett identified the service principal, reconstructed its workload sign-ins, inspected the application's credentials and found the alternative authentication path: a key credential used for certificate-based application authentication.
Then he investigated who configured it, when it became valid, what resources the identity authenticated to and what permissions the service principal held.
No client secret does not mean no credential.
At first glance, that seemed inconsistent with the successful authentication events.
It wasn't.
Agent Foskett identified the service principal, reconstructed its workload sign-ins, inspected the application's credentials and found the alternative authentication path: a key credential used for certificate-based application authentication.
Then he investigated who configured it, when it became valid, what resources the identity authenticated to and what permissions the service principal held.
No client secret does not mean no credential.
Investigation principle: Workload identity investigations must separate the application, the service principal, the credential and the permissions.
Related investigations
Agent Foskett InvestigationsContinue through the complete collection of real-world Microsoft security investigations.KQL Threat HuntingExplore practical investigation techniques across Microsoft Defender XDR and Microsoft Sentinel.SOC Analyst AcademyBuild practical investigation and triage skills across identity, endpoint, email and cloud security.
Final thought
Workload identities do not behave like ordinary users, and their authentication cannot be investigated as though they do.
An application may have no client secret and still authenticate successfully through another supported mechanism.
Identify the application. Identify the service principal. Inspect the credentials. Review the permissions. Then correlate the workload sign-ins with the change history.
Follow the evidence. Build the timeline.
The Logs Already Knew! 🔎
An application may have no client secret and still authenticate successfully through another supported mechanism.
Identify the application. Identify the service principal. Inspect the credentials. Review the permissions. Then correlate the workload sign-ins with the change history.
Follow the evidence. Build the timeline.
The Logs Already Knew! 🔎
