Entra Id Sign in Logs Retention
You manage entra id sign in logs retention by routing login records to external storage. Native cloud identity portals keep these sign in records for a short default window. Teams often set up this log routing to track who enters their cloud apps. Still, teams also grant broad admin roles so engineers can read and export these logs. Broad roles give too many people power over your identity settings and storage accounts. How to set up entra id sign in logs retention First, you need to understa
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 manage entra id sign in logs retention by routing login records to external storage. Native cloud identity portals keep these sign in records for a short default window. Teams often set up this log routing to track who enters their cloud apps. Still, teams also grant broad admin roles so engineers can read and export these logs. Broad roles give too many people power over your identity settings and storage accounts.
How to set up entra id sign in logs retention
First, you need to understand how the identity service stores login events. Every time a user or app logs in, the identity provider creates a record. This record holds the user name, time, location, and device details. The native portal holds these records for a limited number of days. That timeframe depends on the license tier your team owns.
To keep records longer, you must set up a diagnostic routing rule. This rule sends sign in logs out of the identity portal as they happen. You can send these logs to a cloud storage account for cold archiving. You can also send them to a log analytics workspace for fast searches. Some teams route the records to an external security event tool.
Inside the storage destination, you set a retention rule for the data. This rule tells the storage bucket how many days or years to keep files. Once a log file passes that age, the storage service deletes it. You must also lock down the roles that can change these storage rules. If an attacker gets a broad storage role, they can wipe your log history.
What sign in logs miss during live database and server sessions
Keeping sign in logs for a long time solves a key audit need. It proves who logged into your cloud portal on a past date. Auditors ask for this proof during security reviews. It also helps your security team spot strange login patterns over many months.
Still, sign in logs only show the front door. They tell you that an engineer logged in at nine in the morning. They do not show what that engineer did inside your systems after logging in. A sign in log cannot see a bad SQL query running on a database. It cannot see a command that drops a table or exports customer rows.
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.
After a user passes the identity check, they often connect to servers and databases. In many setups, they use shared database roles or standing cloud permissions. At that point, the identity sign in log stops tracking their actions. If someone pulls thousands of email addresses or card numbers, the login log looks normal. You need controls that watch and restrict individual queries and commands in flight. You also need data masking that rewrites emails, phone numbers, and national IDs in results.
How to lock down log storage roles and audit trails
When you export identity logs, you create a new target for attackers. Those archived logs hold sensitive details about your team and system habits. You should separate the role that sets up log routing from the role that reads logs. Give your security auditors read permissions on the log workspace only.
Do not give engineers standing admin roles on the identity portal just to check logs. Also, use immutable storage locks on your long term archive buckets. An immutable lock stops anyone from deleting log files before the retention timer ends. Even a top admin cannot delete locked files early. Still, locking down login archives only protects the record of who entered the building. To protect the actual data, you must control each command and query inside your systems.
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
How long does the portal keep sign in logs by default?
The built-in retention window depends on your active identity license tier. Free tiers keep logs for a shorter time than paid enterprise tiers. For long term storage, you must route logs to an external storage account.
Where should we send sign in logs for long retention?
Use a cloud storage account if you only need cheap, long term archive files. Use a log workspace or security event tool if you need to run fast searches.
Do sign in logs show what queries a user ran in a database?
No, sign in logs only record the login event and token check. They do not capture SQL queries, shell commands, or API calls made during a session.