Reviewing Sign-In Logs in Entra ID: What Normal and Suspicious Look Like

Microsoft Entra ID sign-in logs are one of the most valuable sources of evidence available to a Microsoft 365 administrator.

They can show who attempted to sign in, which application they accessed, where the request appeared to originate, which device was used, whether multi-factor authentication was completed and which Conditional Access policies affected the result.

However, a long list of successful and failed sign-ins is not automatically useful.

Administrators need to understand the difference between:

• Normal employee activity
• Expected technical background traffic
• User mistakes
• Misconfigured applications
• Password attacks
• Token theft
• Suspicious authentication flows
• Successful account compromise

Microsoft Entra records several categories of sign-in activity, and the event details can be used for security investigations, compliance and troubleshooting. Microsoft recommends examining fields such as authentication details, device information, network location, Conditional Access results and risk information when interpreting an event. 

This guide explains how to review sign-in logs in Microsoft Entra ID, what normal activity usually looks like and which warning signs deserve immediate investigation.

What Are Microsoft Entra Sign-In Logs?

Microsoft Entra sign-in logs record authentication activity involving identities and applications in your tenant.

Depending on the sign-in type and licensing available, the logs may include activity involving:

• Employees
• Administrators
• Guest users
• Service principals
• Managed identities
• Microsoft 365 applications
• Third-party enterprise applications
• Mobile applications
• Browser sessions
• Desktop clients
• Automated processes

A sign-in record can contain details such as:

• User
• Application
• Resource
• Date and time
• IP address
• Approximate location
• Device
• Operating system
• Browser
• Authentication method
• Sign-in result
• Failure reason
• Conditional Access result
• Sign-in risk
• Risk detections
• Session information

Microsoft Entra logs tenant sign-ins and provides several views so administrators can investigate interactive users, non-interactive activity and workload identities separately. 

Why Sign-In Logs Matter

Sign-in logs can help answer questions such as:

• Did the user enter the wrong password?
• Was MFA completed successfully?
• Did Conditional Access block the request?
• Was the device compliant?
• Did the sign-in originate from an expected network?
• Was an old application using legacy authentication?
• Did an attacker successfully access the account?
• Did the same account appear in two distant locations?
• Was device code flow used?
• Was the account marked risky?
• Did an application obtain access without normal user interaction?

The logs are useful for both security and support.

A failed sign-in is not always an attack. It may be caused by:

• An expired password
• A cached credential
• A disconnected mobile application
• An old Outlook profile
• A Conditional Access requirement
• An unregistered MFA method
• An unsupported browser
• A non-compliant device

Likewise, a successful sign-in is not automatically safe. An attacker using a stolen password, session token or approved OAuth application may produce a successful event.

Where to Find Sign-In Logs

In the Microsoft Entra admin centre:

1. Open Microsoft Entra ID.
2. Select Monitoring & health.
3. Open Sign-in logs.
4. Choose the appropriate sign-in category.
5. Apply filters to narrow the results.
6. Select an event to open its detailed information.

The available categories may include:

• Interactive user sign-ins
• Non-interactive user sign-ins
• Service principal sign-ins
• Managed identity sign-ins

The exact menu layout and fields may change as Microsoft updates the Entra admin centre, but the sign-in logs remain the primary place to investigate authentication outcomes. 

Interactive User Sign-Ins

Interactive sign-ins occur when a user actively participates in authentication.

Examples include:

• Entering a password
• Completing an MFA prompt
• Using a passkey
• Tapping a FIDO2 security key
• Signing in through a browser
• Unlocking access with Windows Hello for Business
• Authenticating through a federated identity provider

Microsoft’s interactive sign-in logs record user-driven authentication events and can include the individual authentication steps completed during the request. 

These are usually the easiest events to explain because the user may remember the activity.

Non-Interactive User Sign-Ins

Non-interactive sign-ins happen when an application or operating system obtains or refreshes access without displaying a new sign-in prompt to the user.

Examples may include:

• Outlook refreshing a token
• Teams maintaining a session
• A mobile application synchronising data
• Windows requesting a token in the background
• An application using a refresh token

A single interactive login can therefore be followed by many non-interactive sign-ins.

This is often normal.

However, non-interactive activity can also reveal stolen or abused tokens. If an account continues accessing resources from an unexpected network, device or application, the activity should be investigated even when no new MFA prompt occurred.

Service Principal and Managed Identity Sign-Ins

Not every sign-in belongs to a person.

Applications and automated workloads may authenticate using:

• Service principals
• Managed identities
• Certificates
• Client secrets
• Federated credentials

These events should be reviewed differently from user sign-ins.

Normal workload activity is usually:

• Predictable
• Limited to known applications
• Associated with expected resources
• Consistent in timing
• Performed from known cloud or network environments

Suspicious workload activity may include:

• A dormant application suddenly becoming active
• Access to an unexpected resource
• A new credential being used
• Activity from an unusual IP address
• A large increase in authentication volume
• An overprivileged application accessing sensitive data

Microsoft Entra ID Protection can also produce risk information associated with suspicious user or service-principal activity, depending on the detection and licensing available. 

Start With a Baseline

You cannot reliably identify abnormal activity until you understand what normal looks like.

Build a baseline around:

• The countries where employees work
• Corporate public IP addresses
• VPN exit points
• Common internet providers
• Standard devices
• Approved operating systems
• Expected browsers
• Normal Microsoft 365 applications
• Typical working hours
• Common travel patterns
• Approved automation identities
• Guest-user behaviour

For example, a London employee using a company-managed Windows laptop through the organisation’s known internet connection is probably normal.

The same user signing in from an unfamiliar device, an unexpected country and an unknown application at 03:00 deserves closer review.

The location displayed in Entra is derived from IP information and should be treated as an investigative clue rather than perfect proof of physical location. Corporate VPNs, mobile providers, privacy services and cloud networks can make a legitimate user appear elsewhere.

What a Normal Sign-In Often Looks Like

A normal sign-in usually fits the user’s established pattern.

For example:

One difference does not automatically mean compromise.

An employee may:

• Replace their phone
• Use hotel Wi-Fi
• Work from another office
• Switch browsers
• Travel
• Use a mobile network
• Connect through a company VPN

The full context matters.

What a Normal Failed Sign-In Looks Like

Normal users generate failures too.

A harmless pattern might include:

1. One or two failed password attempts
2. A successful sign-in shortly afterward
3. The same device and location throughout
4. Access to a normal application
5. No risky-user or risky-sign-in alert

This often indicates a typing mistake or an outdated saved password.

Another common pattern is repeated failures from one known mobile device followed by success after the employee updates the stored password.

The important questions are:

• Did the user recognise the activity?
• Was the source device expected?
• Was the location expected?
• Did the failures stop?
• Was the final authentication legitimate?

Key Sign-In Log Fields to Review

Selecting an event opens several useful sections.

The most important areas normally include:

• Basic information
• Location
• Device information
• Authentication details
• Conditional Access
• Risk information
• Troubleshooting and status information

Microsoft’s sign-in activity documentation explains that these fields help administrators identify why authentication succeeded or failed and which controls were evaluated. 

User and Username

Confirm:

• The user is active.
• The account belongs to the expected person.
• It is not a dormant or former employee account.
• It is not an emergency or service account being used interactively.
• The displayed identity matches the application activity.

High-priority concerns include:

• A disabled employee account attempting access
• A break-glass account signing in unexpectedly
• A shared account used from several locations
• A service account showing interactive activity
• An administrator using a privileged identity for routine applications

Application and Resource

The application is the client requesting access.

The resource is the service or API the application is attempting to reach.

For example:

• Outlook may be the client application.
• Exchange Online may be the resource.

Review whether both are expected.

Suspicious examples include:

• A user accessing an unfamiliar enterprise application
• A finance employee authenticating to an unknown command-line client
• An ordinary user accessing administrative tools
• A legacy application appearing unexpectedly
• A previously unused application requesting Microsoft Graph access

A familiar resource does not make an unfamiliar client safe.

An attacker may use a legitimate-looking or commonly available application to access Exchange Online, Microsoft Graph or SharePoint.

Date and Time

Check the event against:

• The user’s normal working hours
• Known travel
• Scheduled maintenance
• Automated process timings
• Reported suspicious messages
• Password or MFA changes
• Other events around the same time

A sign-in at 02:00 is not automatically malicious. Some employees work unusual hours or travel internationally.

However, unusual timing becomes more concerning when combined with:

• An unfamiliar device
• An unknown IP address
• A new application
• Mailbox changes
• High-risk detections
• Large file downloads

IP Address

The source IP address is one of the most useful investigation fields.

Ask:

• Does it belong to the organisation?
• Is it a known VPN exit address?
• Is it associated with the user’s home or mobile provider?
• Is it from a cloud hosting company?
• Has it appeared for other users?
• Is it linked to repeated failures across many accounts?
• Is it associated with threat intelligence?

One IP attempting many usernames may indicate:

• Password spraying
• Credential stuffing
• Automated reconnaissance
• A misconfigured shared application

Many IP addresses attempting one account may indicate:

• A targeted brute-force attack
• Distributed password spraying
• A compromised username appearing in attacker lists

Location

Entra may display a country, region or city inferred from the IP address.

Treat this carefully.

A user may appear in a different location because of:

• Corporate VPN routing
• Mobile carrier infrastructure
• Satellite internet
• Cloud security proxies
• International travel
• IP geolocation errors

A location becomes more suspicious when it conflicts with other evidence.

For example:

• London sign-in from a compliant company laptop
• Five minutes later, a successful sign-in from another continent
• Different operating system
• Unmanaged browser
• Unfamiliar application

That combination deserves urgent investigation.

Device ID and Registration State

Review whether the device is:

• Microsoft Entra registered
• Microsoft Entra joined
• Hybrid joined
• Managed
• Compliant
• Unknown

An expected managed device provides useful confidence, although it does not guarantee that the sign-in is safe.

An unknown device may be legitimate when:

• The user changed phone
• The user is accessing a permitted browser session
• A guest is signing in
• The business allows personal devices

It is more concerning when an unknown device accesses:

• Administrative portals
• Payroll
• Finance systems
• Security tools
• Large volumes of company data

Operating System and Browser

Compare these fields with the user’s normal equipment.

Examples of anomalies include:

• A Windows-only employee suddenly using Linux
• A user with an iPhone appearing through Android
• A normal Edge user signing in through an unusual automation client
• An unsupported or very old operating system
• A browser type inconsistent with the claimed device

These details can be spoofed and should not be treated as conclusive proof, but they help build the overall picture.

Authentication Details

Authentication details can show the steps used during sign-in.

Review:

• Password authentication
• MFA method
• Passkey or security-key use
• Whether MFA was completed
• Whether MFA was satisfied by a previous claim
• Authentication requirement
• Authentication result
• Sequence of authentication steps

A sign-in may show that MFA was satisfied without a new prompt because the user already had a valid session or token.

This is often normal.

It can also matter during token-theft investigations. An attacker replaying a stolen session may gain access without creating a fresh MFA approval.

MFA Completed Does Not Mean Safe

A successful MFA result proves that the authentication requirement was satisfied.

It does not necessarily prove that:

• The user understood the request
• The correct device initiated it
• The session was not proxied
• The token was not stolen
• The user was not socially engineered
• The application was trustworthy

Attackers may obtain successful authentication through:

• Adversary-in-the-middle phishing
• Device code phishing
• MFA fatigue
• Remote-control abuse
• Stolen tokens
• Malicious OAuth consent

Treat MFA as one evidence point, not an automatic declaration of safety.

Conditional Access Results

The Conditional Access tab shows which policies were evaluated and what happened.

Common results include:

• Success
• Failure
• Not applied
• Report-only success
• Report-only failure
• Excluded

Check:

• Which policies applied
• Which policies did not apply
• Why a policy was skipped
• Which grant controls were required
• Whether an exclusion affected the user
• Whether the policy was in report-only mode
• Whether the device or network met requirements

Microsoft recommends using sign-in logs to troubleshoot unexpected Conditional Access outcomes and identify the exact policy affecting access. 

A successful sign-in may still expose a policy gap when the expected security policy shows Not applied or Excluded.

Sign-In Risk vs. User Risk

These two concepts are related but different.

Sign-In Risk

Sign-in risk estimates the probability that a particular authentication request was not performed by the legitimate user.

Examples of relevant signals may include:

• Unfamiliar sign-in properties
• Malicious IP addresses
• Anonymous networks
• Atypical travel
• Suspicious browser behaviour
• Token anomalies

User Risk

User risk estimates the probability that the identity itself has been compromised.

This may be influenced by:

• Leaked credentials
• Confirmed malicious activity
• Suspicious sign-in patterns
• Previous unresolved detections

Microsoft advises creating separate Conditional Access policies for sign-in risk and user risk rather than combining both conditions in one policy. 

Risk Levels

Depending on licensing and detection availability, a sign-in or user may be classified with a risk level such as:

• Low
• Medium
• High

Do not ignore low-risk events automatically.

A low-risk detection affecting a Global Administrator may deserve more attention than a medium-risk event affecting a low-impact test account.

Prioritisation should consider:

• User privilege
• Data access
• Application sensitivity
• Whether the event succeeded
• Other related detections
• Device trust
• Business context

Common Risk Detections

Microsoft Entra ID Protection can detect several types of suspicious or anomalous identity activity. The exact list evolves as Microsoft updates its detection systems. 

Examples may include:

• Anonymous IP address
• Atypical travel
• Unfamiliar sign-in properties
• Malware-linked IP address
• Malicious IP address
• Password spray
• Leaked credentials
• Suspicious token behaviour
• Threat-intelligence detections

Risk detections are indicators for investigation, not always proof of compromise.

Unfamiliar Sign-In Properties

An unfamiliar-properties detection may be triggered when a sign-in differs from the user’s established behaviour.

Properties may include:

• IP address
• Location
• Device
• Browser
• Network
• Tenant subnet
• Autonomous system number

New employees and recently created accounts may generate more unfamiliar activity because Microsoft has less history available.

A legitimate user may also trigger the detection when:

• Travelling
• Replacing a device
• Changing internet provider
• Using a VPN
• Working from a new office

Confirm the activity with the user through a trusted communication channel.

Atypical or Impossible Travel

Travel-related detections compare sign-ins that appear to originate from geographically distant locations within a short time.

Possible legitimate explanations include:

• VPN usage
• Cloud proxy routing
• Mobile network changes
• Remote desktop services
• Shared accounts
• Incorrect IP geolocation

Suspicious examples include:

• Successful sign-ins from distant countries minutes apart
• Different devices and browsers
• No corporate VPN involved
• Subsequent mailbox or file activity
• No travel reported by the user

Avoid basing the conclusion on location alone.

Password Spray Indicators

Password spraying involves trying a small number of likely passwords across many accounts.

Possible log patterns include:

• One IP address targeting many users
• Similar failure codes
• Attempts spread over time
• Use of common applications or legacy protocols
• A small number of eventual successes

Unlike a traditional brute-force attack, password spraying may not generate hundreds of failures against one user.

It is designed to avoid lockout thresholds.

Investigate any successful sign-in associated with a wider pattern immediately.

Suspicious Successful Sign-Ins

A successful sign-in deserves investigation when it includes one or more of these characteristics:

• Unrecognised country
• Unmanaged or unknown device
• New browser or operating system
• Unfamiliar application
• High or medium risk
• Unexpected authentication flow
• Access outside normal hours
• Administrator or finance user
• New MFA method added shortly before or after
• Mailbox forwarding or inbox rules created
• Unusual data downloads
• Activity continuing after the user says they signed out

Success means access was granted. It does not mean the access was legitimate.

Suspicious Failed Sign-Ins

Failed sign-ins become suspicious when they form a pattern.

Watch for:

• Large numbers of users targeted from one IP
• Repeated attempts against administrators
• Attempts using legacy authentication
• Failures from many countries
• Attempts against disabled or dormant accounts
• Device code flow where it is not expected
• Repeated MFA interruptions
• Attempts immediately followed by a successful login

An attack may contain thousands of failures and only one success.

The successful event is the one that matters most.

Interrupted Sign-Ins

A sign-in may be interrupted because the user must complete another action.

Examples include:

• MFA registration
• MFA challenge
• Password change
• Terms-of-use acceptance
• Device compliance
• Additional Conditional Access requirement

Interrupted does not necessarily mean blocked or malicious.

Review the status details and authentication sequence to see what was required and whether the process later completed.

Error Codes and Failure Reasons

The sign-in event normally includes:

• Status
• Error code
• Failure reason
• Additional details

These can explain whether the failure involved:

• Incorrect credentials
• Conditional Access
• Account lockout
• Disabled account
• Expired password
• MFA failure
• Device requirements
• Application configuration
• Risk-based blocking

For Conditional Access problems, the policy tab is often more useful than relying only on the numeric error code. Microsoft specifically recommends reviewing the sign-in record to determine which access control caused the result. 

Device Code Flow

Device code flow is a legitimate authentication process used by some input-constrained devices and applications.

It can also be abused for phishing.

In a device code attack:

1. An attacker starts a device authentication session.
2. The attacker sends the code to the victim.
3. The victim enters it on Microsoft’s genuine website.
4. The victim completes authentication.
5. The attacker receives the authorised token.

Review device code usage when:

• The organisation has no known requirement for it
• The user is an ordinary office employee
• The application is unfamiliar
• The source network is unexpected
• The sign-in is followed by suspicious activity

Conditional Access can target and block device code flow, and Microsoft recommends controlling higher-risk authentication flows through explicit policies. 

Legacy Authentication

Older protocols may not support modern MFA and Conditional Access controls correctly.

Possible signs include:

• Client app listed as an older authentication client
• Repeated failures from email protocols
• Sign-ins from outdated Office clients
• Activity from multifunction printers or scanners
• Shared mailbox applications using stored passwords

Legacy authentication should generally be blocked after legitimate dependencies have been identified and replaced.

A successful legacy-authentication event deserves immediate attention because it may represent a path around stronger modern controls.

Administrator Sign-Ins

Administrative identities deserve stricter scrutiny.

Review:

• Every unusual administrator sign-in
• Access from unmanaged devices
• Access through unfamiliar applications
• Role activation and changes
• Failed attempts from unexpected countries
• Emergency-account activity
• Sign-ins outside normal administrative windows
• MFA methods used
• Whether phishing-resistant authentication was required
• Whether the admin account accessed ordinary email or collaboration tools

A Global Administrator sign-in should not be treated with the same risk tolerance as a low-privilege user accessing a public information application.

Emergency Access Account Activity

A break-glass account should be almost completely inactive.

Investigate every:

• Successful sign-in
• Failed sign-in
• Password change
• Authentication-method change
• Role change
• Group membership change
• Conditional Access exclusion change

Expected testing should be scheduled, documented and correlated with alerts.

Any unscheduled use should be treated as a high-priority security incident.

Guest-User Activity

Guest sign-ins can look different from internal-user activity.

A guest may:

• Authenticate through another tenant
• Use an external identity provider
• Access from an unmanaged device
• Work from a different country
• Satisfy MFA in their home organisation

Confirm:

• The guest is still required.
• The project is active.
• The application is expected.
• The guest’s organisation is known.
• Their access scope remains appropriate.
• The sign-in behaviour fits the engagement.

Old guest identities are easy to overlook and should be reviewed regularly.

How to Investigate a Suspicious Sign-In

Use a structured process.

1. Record the Event

Capture:

• User
• Time
• IP address
• Location
• Application
• Resource
• Device
• Browser
• Authentication method
• Risk level
• Conditional Access result
• Correlation or request identifier

Do not rely only on screenshots when the event can be exported or retained through your logging platform.

2. Compare Nearby Activity

Review sign-ins:

• Before the event
• After the event
• From the same IP
• From the same device
• To the same application
• For the same user
• For other users in the tenant

A suspicious event often makes more sense as part of a sequence.

3. Contact the User

Use a known trusted method.

Do not reply to a suspicious email or Teams conversation that may be controlled by an attacker.

Ask:

• Did you sign in at this time?
• Were you travelling?
• Did you use this device?
• Did you approve an MFA prompt?
• Did you enter a device code?
• Did you install software or a browser extension?
• Did you open an unusual link?

Avoid telling the user every detail before asking, as leading questions can reduce the value of their recollection.

4. Review Identity Protection

Check:

• Risky sign-ins
• Risky user status
• Risk detections
• Risk history
• Related authentication events

Microsoft recommends using the user’s risk history and correlated sign-in activity when determining whether credentials or sessions were abused. 

5. Review Audit Activity

Look for:

• New MFA methods
• Password changes
• Role assignments
• Group membership changes
• Application consent
• Conditional Access changes
• Mailbox configuration changes
• New forwarding settings
• Inbox rules

6. Review Endpoint Security

Check whether the device has:

• Malware detections
• Information-stealer alerts
• Suspicious browser extensions
• Remote-access software
• Credential theft
• Unusual processes
• Security-control tampering

7. Contain the Account

When compromise is likely:

• Block or disable the account where appropriate
• Revoke active sessions
• Revoke refresh tokens
• Reset the password
• Remove unknown authentication methods
• Revoke malicious application consent
• Isolate affected devices
• Preserve evidence

Microsoft’s remediation guidance includes using Conditional Access and administrative action to secure users and sessions when risk is confirmed. 

Do Not Dismiss Risk Without Evidence

Risky sign-ins may be false positives, but they should not be dismissed merely because:

• The user says they recognise the country
• MFA succeeded
• The login was successful
• The IP belongs to a large cloud provider
• No immediate damage is visible

Confirm the complete context.

When marking activity safe, record:

• Who investigated it
• What evidence was reviewed
• Why it was considered legitimate
• Whether further controls are required

Incorrectly dismissing a real compromise can remove useful risk signals and reduce the urgency of later investigation.

What to Do When the Sign-In Is Confirmed Safe

When evidence shows the activity was legitimate:

1. Document the reason.
2. Mark or dismiss the risk appropriately.
3. Update known-location or device documentation if necessary.
4. Help the user correct any configuration problem.
5. Adjust policies only when a genuine business requirement exists.
6. Avoid creating broad exclusions to fix one isolated event.

A false positive can still reveal an improvement opportunity, such as an undocumented VPN range or an unregistered company device.

What to Do When the Sign-In Is Confirmed Compromised

Treat it as an identity incident.

Actions may include:

• Confirm the user as compromised
• Block sign-in
• Revoke sessions and tokens
• Reset credentials
• Re-register MFA securely
• Remove unknown passkeys or security keys
• Review mailbox rules
• Review OAuth applications
• Review files accessed or downloaded
• Search for messages sent by the attacker
• Investigate lateral movement
• Notify affected parties
• Preserve logs
• Review the device
• Increase monitoring after recovery

Do not restore access until the attacker’s persistence methods have been removed.

Filters Worth Using

Useful filters include:

• User
• Application
• Status
• IP address
• Location
• Conditional Access result
• Client application
• Authentication protocol
• Sign-in risk
• Date range
• Device information
• Resource

Start narrow.

For example:

User: finance.manager@company.com

Date: Last 24 hours

Status: Failure

Then expand the investigation when needed.

A Daily Review Routine

For smaller organisations, a practical daily check may include:

• High-risk sign-ins
• Medium-risk administrator sign-ins
• Successful legacy-authentication events
• Emergency-account activity
• Unusual country activity
• Repeated failures across many users
• Unexpected device code flow
• New administrative sign-ins
• Accounts with recently changed MFA methods

The routine should be proportionate to the business’s risk and available monitoring tools.

A Weekly Review Routine

A weekly review may include:

• Top failed-sign-in IP addresses
• Most frequently targeted users
• Dormant or disabled accounts receiving attempts
• New countries and networks
• Unmanaged-device access
• Guest sign-in activity
• Conditional Access failures
• Policies unexpectedly not applying
• Workload identities with unusual activity
• Risk trends
• Repeated user support problems

Reviewing trends is often more useful than examining isolated events.

Send Logs to a SIEM

Larger organisations should consider sending Entra sign-in and risk information to a central security platform.

This allows correlation with:

• Endpoint alerts
• Email threats
• Firewall traffic
• VPN activity
• Cloud application events
• File downloads
• Privileged-role changes
• Threat intelligence

Microsoft notes that Identity Protection risk data can be used in Conditional Access or exported to a security information and event management platform for investigation and correlation. 

Sign-In Log Retention

Retention depends on licensing, configuration and whether logs are exported to another platform.

Do not assume the Entra portal will retain enough history for every investigation or compliance requirement.

Define:

• Required retention period
• Export destination
• Access controls
• Alerting
• Archive protection
• Search procedures
• Incident evidence requirements

Security investigations often begin weeks after the first malicious sign-in.

Common Sign-In Review Mistakes

Investigating Only Failed Sign-Ins

Successful malicious authentication creates greater immediate risk.

Trusting Location Too Much

VPNs and mobile providers can distort geolocation.

Assuming MFA Means the User Is Safe

The user may have approved a malicious transaction or the attacker may have stolen a token.

Ignoring Non-Interactive Sign-Ins

Token abuse often appears through background activity.

Looking at One Event in Isolation

Compromise is usually visible as a sequence.

Ignoring Application and Resource Names

The account may be accessing an unexpected service.

Dismissing Risk Too Quickly

Investigate before changing the risk status.

Ignoring Workload Identities

Applications can be compromised too.

Failing to Review Conditional Access

A successful sign-in may reveal that the expected policy never applied.

Keeping Logs for Too Short a Period

The original evidence may be gone by the time an incident is discovered.

Sign-In Investigation Checklist

Identity

• Is the account active?
• Is the user high risk or privileged?
• Does the user recognise the event?
• Has the account recently changed role or owner?

Sign-In Context

• Is the time expected?
• Is the location expected?
• Is the IP known?
• Is the application approved?
• Is the resource appropriate?
• Is the authentication flow expected?

Device

• Is the device known?
• Is it managed?
• Is it compliant?
• Does the operating system match the user?
• Is the browser expected?

Authentication

• Which methods were used?
• Was MFA newly completed or previously satisfied?
• Was phishing-resistant authentication used?
• Was device code flow involved?
• Were there unusual failures before success?

Security Controls

• Which Conditional Access policies applied?
• Were any expected policies skipped?
• Was an exclusion involved?
• Was the policy active or report-only?
• Was the sign-in marked risky?

Related Activity

• Were MFA methods changed?
• Were inbox rules created?
• Was forwarding enabled?
• Were files downloaded?
• Was OAuth consent granted?
• Were roles or groups changed?
• Did endpoint protection generate alerts?

Final Thoughts

Microsoft Entra sign-in logs are not simply a list of logins.

They are a record of how identities, devices, applications and security controls interacted during every authentication attempt.

Normal activity usually fits an established pattern:

• Familiar user
• Expected application
• Known device
• Reasonable location
• Successful Conditional Access
• No unexplained risk detections

Suspicious activity often combines several anomalies:

• Unexpected country or IP
• Unknown device
• Unfamiliar application
• Unusual authentication flow
• Missing Conditional Access protection
• Risk detections
• Mailbox or account changes afterward

No single field should decide the outcome of an investigation.

A strange location may be a VPN. A failed password may be a typing mistake. A successful MFA event may still be the result of phishing.

The strongest investigations combine sign-in logs with user confirmation, audit activity, endpoint evidence, Identity Protection and application logs.

Review the logs regularly, establish a clear baseline and build a documented process for containing suspicious activity. When an account is compromised, the difference between checking the logs today and checking them next week can be the difference between a contained incident and a serious business breach.

Unsure What Your Microsoft Entra Sign-In Logs Are Telling You?

Hamilton Group can help your business review Microsoft Entra ID and Microsoft 365 authentication activity.

Our experts can help you:

• Investigate suspicious sign-ins
• Review risky users and risk detections
• Audit Conditional Access results
• Identify password-spray activity
• Detect device code and token-based attacks
• Review administrator and break-glass account activity
• Configure identity alerts
• Improve sign-in-log retention
• Integrate Entra logs with security monitoring
• Build account-compromise response procedures
• Strengthen Microsoft 365 identity security

Visit hgmssp.com, call Hamilton Group on 0330 043 0069, or book a meeting with one of our experts to review your Microsoft Entra sign-in security.