An Entra application investigation needs configuration changes, permission grants, sign-in evidence and resource activity. This guide explains portal aggregation, stable identifiers, table-schema traps and retention limits, then proposes a disciplined way to test both suspicious and benign explanations.
At a glance
Key findings
- A service-principal sign-in row can summarize several matching events; expand the record before treating portal rows as event counts. [1]
- In the referenced Log Analytics table,
TenantIddenotes the workspace ID. Field names must be interpreted from that table's schema. [2] - A successful sign-in does not establish which data operations occurred. Preserve resource evidence and authority changes separately.
Define the application and the evidence window
An unexpected application sign-in is a starting point, not a complete incident. The investigator needs to determine which identity authenticated, what authority it held, who could change its credentials and what happened at the target resource. Beginning with those questions prevents a successful authentication record from becoming an unsupported claim about data access.
Record the application ID, service-principal object ID, relevant directory and target resource. Add the period under investigation and the reason it was chosen. Keep display names for readability, but use stable identifiers to distinguish similarly named applications and different representations of an application across environments.
Create separate evidence groups for configuration changes, permission grants, authentication and resource operations. Add the organization's deployment or change record as another source. The point is not to force every group into one joined table immediately. It is to preserve enough context to explain which relationships are established and which are still hypotheses.
From a permission grant to a resource sign-in
Corroborate application control, authority and authentication with separate records before concluding what the application did.
Source. Primary documentation [1] [2] [3] [4] [5]. Accessed August 28, 2026.
Method. Original investigation evidence map based on Microsoft documentation. Arrows identify relationships that require corroboration. This is not an observed incident timeline or a claim that all sources share a correlation identifier.
Accessible table and figure data
| Record family | Useful key | Question |
|---|---|---|
| Application change | Application or service-principal ID | Who changed control of the identity? |
| Permission grant | Client and resource IDs | Which authority was added? |
| Service-principal sign-in | Principal, resource and credential ID when present | Which identity authenticated to which resource? |
| Business change record | Approved deployment or rotation reference | Is there a supported benign explanation? |
| Retention/export record | Category and date window | Which missing evidence can no longer be recovered? |
| Record family | Useful key | Question |
|---|---|---|
| Application change | Application or service-principal ID | Who changed control of the identity? |
| Permission grant | Client and resource IDs | Which authority was added? |
| Service-principal sign-in | Principal, resource and credential ID when present | Which identity authenticated to which resource? |
| Business change record | Approved deployment or rotation reference | Is there a supported benign explanation? |
| Retention/export record | Category and date window | Which missing evidence can no longer be recovered? |
Expand the sign-in before counting it
Microsoft explains that the service-principal sign-in view can aggregate matching entries and that investigators can expand a row to see individual timestamps. It also distinguishes service-principal sign-ins from managed-identity sign-ins. Counting visible rows or searching the wrong identity log can therefore misstate the activity being examined. [1]
Before reporting a frequency or a first-seen time, identify whether the source is a grouped portal view or exported individual records. Retain the filters, time zone and expansion state used to obtain the result. If the evidence package contains only a screenshot, state what the screenshot cannot establish about the underlying event count.
Do not treat the absence of an interactive user as inherently suspicious. The application may be designed to operate unattended. Instead, ask whether the principal, target resource, credential context and timing fit the expected integration. A difference from the application's approved operating pattern is more informative than a generic statement that service accounts do not resemble human sign-ins.
Choose schema fields deliberately
The AADServicePrincipalSignInLogs reference defines identifiers and authentication context available in the Log Analytics table. Its TenantId field is the Log Analytics workspace ID, not a safe shortcut for the Entra directory identifier. Other fields can describe the application, service principal, resource and credential context, with availability depending on the record. [2]
Document the meaning of each field used in a query or join. Do not choose a field because its name resembles a field in another service's table. Preserve the original value and the schema reference in the analysis notes. This is especially important when several teams contribute exports from different workspaces, directories or resource services.
Prefer explicit join candidates over silent assumptions. A matching application ID may connect two records at one level, while a credential identifier, object ID or time window narrows the question further. If a field is absent, retain that limitation. Replacing a missing value with a display name can make a table look complete while weakening the attribution it appears to support.
Reconstruct the authority changes
Microsoft documents audit activities for application permissions and consent, including changes to app-role assignments and delegated permission grants. These records describe different changes in authority. A consent-related event and an application permission grant should be interpreted according to their activity type rather than collapsed into an undifferentiated “permissions changed” label. [3]
Build a bounded sequence of relevant changes before the sign-in. Identify the actor, target application or service principal, permission or grant involved and the recorded outcome. Compare the resulting authority with the previously approved state. Keep a distinction between a request to change access, a successful grant change and an authentication event that follows it.
Then ask what evidence would show the authority being used. A sign-in to a resource and a resource operation are different records. If the investigation lacks the resource's activity logs, state that the available evidence supports authentication or grant history only. Do not infer a particular read, write or export solely from the fact that the application possessed a permission capable of performing it.
Keep event time and collection time distinguishable in the working timeline. Record the time zone used for presentation and preserve the original timestamp. This prevents an export or query-ordering choice from silently becoming an assertion about the sequence of application changes.
Test the benign explanation
Microsoft's application security-operations guidance emphasizes monitoring application changes and investigating unexpected credential, permission and ownership activity. These events can reveal changes in who controls an application, but an unusual change is not automatically a compromise. The investigation needs the business and deployment context alongside the technical records. [4]
Consider a scheduled credential rotation. The observed sequence might include a configuration change followed by sign-ins using the updated credential. Ask for the approved change record, the operator identity, the expected target application and the planned timing. Compare those facts with the logs instead of accepting an informal statement that “the team was doing maintenance.”
Keep competing explanations visible until evidence distinguishes them. A legitimate rotation, an incorrect deployment and unauthorized credential addition can initially share some observable features. Record which detail supports or contradicts each explanation. If the relevant actor or credential field is unavailable, the final confidence statement should reflect that gap rather than relying on a convincing narrative.
Preserve what the investigation cannot recover
Entra's documented default audit and sign-in retention varies by license, including seven days for the free tier and 30 days for relevant premium tiers. Microsoft notes that upgrading does not recover records already expired. Exported records and Microsoft 365 audit records have their own arrangements and should not be treated as one interchangeable history. [5]
State the evidence window actually available for each record family. If the sign-in records survive but the grant history has expired, the investigator may be unable to establish when the authority was created from those sources alone. Preserve that distinction even when another team's operational records provide a plausible explanation.
The investigation handoff should contain stable identity keys, source-specific time windows, the grant changes found, the sign-in interpretation and any resource operations corroborated. Include the approved change record only as its own evidence, not as a replacement for missing telemetry. That structure allows another analyst to challenge the conclusion without having to reconstruct how a portal row became an incident claim.
Method and provenance
Documentation review and original operational analysis using the cited primary sources, checked on August 28, 2026. The editorial date places the article in the retrospective series; publication and source review occurred in August 2026.
No tenant, application or incident was investigated. Fields and retained history can be incomplete. Authentication evidence does not establish a specific resource operation, and different audit systems are not interchangeable. No empirical tests were performed for this article.
AI assistance. Researched, drafted and checked against cited sources with AI assistance. No independent human editorial review or original empirical testing is claimed.
Published under the Cloud Security Desk organizational byline. Read the series policy.
References
- What are service principal sign-ins in Microsoft Entra Microsoft. Accessed .
- AADServicePrincipalSignInLogs table reference Microsoft. Accessed .
- View activity logs of application permissions Microsoft. Accessed .
- Microsoft Entra security operations for applications Microsoft. Accessed .
- Microsoft Entra data retention Microsoft. Accessed .