Entra Id Log Retention
You set up entra id log retention by sending sign-in and audit logs to external storage. The directory holds these logs for a short window before it deletes them. Most security teams route these events to a cloud log workspace or a storage account. When admin roles are too broad, anyone with workspace rights can read or delete those stored logs. Teams must lock down storage roles early to keep audit trails safe. How entra id log retention works in practice Your directory records three main ty
Microsoft Entra ID (Azure AD) + Log Retention Policies: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up entra id log retention by sending sign-in and audit logs to external storage. The directory holds these logs for a short window before it deletes them. Most security teams route these events to a cloud log workspace or a storage account. When admin roles are too broad, anyone with workspace rights can read or delete those stored logs. Teams must lock down storage roles early to keep audit trails safe.
How entra id log retention works in practice
Your directory records three main types of events for your team. Sign-in logs show when users and apps log in to your systems. Audit logs track changes made to users, groups, and roles inside the directory. Provisioning logs show when the directory creates or updates accounts in other apps.
The native portal only keeps these records for a limited number of days. Once that time passes, the system deletes the old records for good. To keep data longer, admins set up diagnostic settings in the portal. These settings stream new events out to a separate destination as they happen.
Teams usually pick one of three destinations for their exported logs. A log analytics workspace lets security teams run fast searches over recent data. A cloud storage account holds cold data in buckets for many years at low cost. Event hubs stream the logs straight to an external security tool for alerts. Many teams use a mix of workspaces for fast checks and storage accounts for long archives.
What native log retention solves and what it misses
Exporting directory logs solves the basic problem of proving who logged in and when. Auditors can check the archive to see when an admin added a user to a group. Security teams can search old sign-in events to trace a stolen account after a breach. It gives you a clear record of identity changes and login events across your team.
Still, directory logs only track the front door of your systems. They show that an engineer logged in and got a token for a database or server. They do not record what that engineer did inside the database or server after logging in. If someone runs a bad query or reads a table of card numbers, directory logs miss it.
Microsoft Entra ID (Azure AD) + Log Retention Policies: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Native retention also cannot control or mask data during a live session. An engineer with a valid role can still pull emails, phone numbers, or national IDs in plain text. Keeping the login event for seven years does not stop a bad command in flight. To protect production data, teams need controls that check and log every query and command.
Managing storage roles and audit rules
Storing logs outside the directory creates a new set of permissions to manage. If engineers have broad roles on the cloud subscription, they might view or delete the log buckets. Security teams must put the storage account in a separate subscription with strict role assignments. Only the security team and auditors should have permission to read those archived files.
Teams should also lock the storage containers so nobody can change or erase old files. Immutable storage rules stop even top admins from wiping the trail after a mistake or attack. Finally, set clear lifecycle rules so the bucket deletes logs only after your required retention period ends.
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 inline in the protocol beside the service as an open-source proxy, a sidecar for your database or API. On every production query an agent or human runs, hoop.dev decides whether to pass, mask, block, or escalate it for review.
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 approval, and hoop.dev data masking rewrites sensitive fields in responses in memory. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Can I extend log retention inside the directory portal itself?
No, the built-in portal uses fixed retention windows based on your license tier. To keep logs longer, you must route them to external cloud storage or a log tool.
Do exported directory logs show the database queries an engineer ran?
No, directory logs only show login events, token grants, and role changes. They do not capture SQL statements, shell commands, or API calls made during a session.
Are old logs exported when I turn on diagnostic settings?
Diagnostic settings only stream new events from the moment you save the rule. You must download older logs manually from the portal before they expire if you need them.