Entra Id Sign-in Logs
You can view entra id sign in logs in your directory portal to track logins. These records show who logged in, which app they opened, and whether the login worked. Security teams check these events every day to find strange login patterns or failed checks. Still, teams often grant broad directory roles just to read these records. Broad roles let users see too much data or change system settings by mistake. How entra id sign in logs work in your directory Your cloud directory writes a new log
Microsoft Entra ID (Azure AD) + PII in Logs Prevention: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You can view entra id sign in logs in your directory portal to track logins. These records show who logged in, which app they opened, and whether the login worked. Security teams check these events every day to find strange login patterns or failed checks. Still, teams often grant broad directory roles just to read these records. Broad roles let users see too much data or change system settings by mistake.
How entra id sign in logs work in your directory
Your cloud directory writes a new log record every time a user or service logs in. The system groups these events into four main types of login activity. Interactive logins happen when a real person types a password or approves a prompt. Non-interactive logins happen when an app or script logs in silently in the background. Service principal logins track when automated tools or servers log in with their own keys. Managed identity logins show when cloud resources talk to other cloud services on their own.
Each log record holds key facts about the login attempt. You can see the user name, the target app, the IP address, and the device location. The log also shows if conditional rules ran and if multi-factor checks passed or failed. To read these records, an admin must hold a reader role in the directory. Good teams assign the smallest reader role instead of a full admin role. Teams also route these logs to a central log workspace for long-term storage and search.
What login logs solve and what they miss
Directory login logs are great for spotting bad login attempts from strange places. They help you prove that a user passed a multi-factor check before opening an app. They also help you fix broken rules when a good user cannot log in. If an attacker guesses passwords, the failed login count jumps right away in the logs.
Still, login logs only tell you what happened at the front door. Once a user logs into a database tool or server, the directory stops watching. The login log shows that an engineer opened a cloud console or database client at noon. It does not show which SQL queries or shell commands that engineer ran at 12:05. It also cannot stop a logged-in user from pulling sensitive fields like emails or card numbers. If an AI agent uses a shared service key, the directory only sees the key login. You still lack visibility into every single query or command that runs inside the session.
Microsoft Entra ID (Azure AD) + PII in Logs Prevention: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
How to tighten control beyond the login event
To close this gap, teams must link directory identity to every action inside a session. Start by removing shared database accounts and static server keys from your team workflows. Map each person and service to their own directory user or group. Next, require approval for high-risk commands rather than granting full standing roles for all tasks. Finally, log every individual statement and mask sensitive fields like phone numbers or national IDs in results.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between interactive and non-interactive sign-in logs?
Interactive logs record when a person enters credentials or completes a prompt on a screen. Non-interactive logs record background logins made by apps or tokens without asking the user.
How long does the directory keep sign-in logs by default?
Built-in retention depends on your directory license tier and normally covers a short window of weeks. For longer history, you must export the logs to an external storage account or log tool.
Do sign-in logs show what a user did inside a database or server?
No, directory sign-in logs only record the initial login event and token checks. They do not capture SQL queries, terminal commands, or data reads that happen after login.