Entra Sign in Logs Retention
You set up entra sign in logs retention by routing login records to external cloud storage. The built-in directory only keeps login events for a short window before deleting them. Security teams often grant broad read roles so staff can check those saved records. Broad roles let too many users read sensitive login data and cloud storage buckets. How to set up entra sign in logs retention The directory records every user login, service login, and token check in real time. Built-in storage hold
PII in Logs Prevention + Single Sign-On (SSO): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up entra sign in logs retention by routing login records to external cloud storage. The built-in directory only keeps login events for a short window before deleting them. Security teams often grant broad read roles so staff can check those saved records. Broad roles let too many users read sensitive login data and cloud storage buckets.
How to set up entra sign in logs retention
The directory records every user login, service login, and token check in real time. Built-in storage holds these records for a brief period based on your license tier. Once that window closes, the directory purges the old login records forever. To keep records longer, teams route the data stream to an external workspace. You can send the stream to a log workspace, a storage account, or an event hub.
A log workspace lets your team run search queries across months of login history. A storage account holds cold data in cheap buckets for multi-year audit rules. An event hub pushes login records to outside security tools as events happen. You pick the categories of login events you want to forward in the settings. You must include interactive user logins, non-interactive logins, service logins, and managed identity events. Each category writes to its own table or storage container in your cloud account. Admin roles must govern who can change the export rules or delete stored files.
What login log storage solves and what it misses
Long-term login logs help your team spot stolen accounts and trace past attacks. Auditors also ask for months of login history to check your security controls. Having these records in a workspace proves when a user logged into an app. It also shows the device state, location, and risk score at login time.
Still, login logs only show the front door of your systems. They tell you who logged in and when the session started. They do not record what the engineer or script did after logging in. Once a user gets a token for a database or server, login logs go blind. The directory cannot see which database queries ran or which shell commands executed. It also cannot stop a bad command or mask sensitive data in query results. If a user runs a broad select query on customer emails, the login log stays silent. You see a clean login event while raw phone numbers or card numbers leave the database.
PII in Logs Prevention + Single Sign-On (SSO): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Closing the gap between login logs and session actions
Security teams need visibility into both the initial login and every action that follows. Storing identity records for a year solves only the first half of the audit puzzle. You also need a way to check and record each query or command in flight. Tying identity context to live database queries and server commands closes this visibility gap. Teams can then enforce fine-grained rules on every single request instead of just the login. Masking rules can rewrite emails and national IDs in results before data reaches the screen. That way, your audit trail shows both the directory login and the exact work done.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Why do built-in directory logs disappear after a short time?
The identity directory acts as a live login service, not a long-term data archive. It keeps recent events for quick checks and requires external storage for long retention.
Which login types should we export to our storage workspace?
Export interactive logins, non-interactive logins, service principal logins, and managed identity logins together. Attackers often use background tokens and app keys that never show up in interactive logs.
Do directory sign in logs show database queries or server commands?
No, directory logs only record when a user or service gets a login token. They never capture the SQL statements, API calls, or shell commands run during the session.