Security Alerts
What this screen is for
Security alerts lists events in your tenant that someone must look at. Today that is a break-glass sign-in: a designated member entered your tenant through Emergency access with a security key. An alert is not a passing condition: it stays open, whatever its age, until an administrator acknowledges it. The header bell lists the open ones, and its View all security alerts link, like the alert e-mail, opens this screen.
What must exist first
- The permission to read your tenant's security alerts, held by every built-in tenant role. Without it the screen names the permission it needs.
- To acknowledge, the permission to acknowledge security alerts, held by the tenant administrator only.
Decisions you make here
Reading the alerts
Choose Open, Acknowledged or All. Each alert shows what happened, its severity, the Identity it is about, when it Occurred, the Session it opened, and, once acknowledged, who acknowledged it, when and the Note.
Acknowledging an alert
Acknowledge records that you looked at the event, with your identity, the time and an optional note of at most 1,000 bytes of UTF-8 text, where an accented letter counts two. The alert and the audit record of the sign-in stay as they are, and the acknowledgment is written to your audit log. An alert is acknowledged once; a second attempt is refused and the first is kept.
A break-glass session cannot acknowledge an alert, not even the one it raised: sign in normally first, as the same person if you like. A platform operator acting inside your tenant through support access cannot acknowledge it either. The platform can read your alerts but never acknowledges them.
How it relates to other screens
Members are designated for break-glass access in their sheet on the users screen, and the tenant's readiness is shown with how members sign in: