Access reviews

Access reviews assess the recorded Microsoft 365 group owner and member roles of a governed, group-connected SharePoint workspace. They do not certify complete effective SharePoint access or review item-level permissions and sharing links. A person who is both owner and member has two distinct roles to decide on.

1. An administrator creates a review, or the configured review scan creates one.
2. Owners receive a review notification with a link.
3. The reviewer signs in through Microsoft Entra with the assigned owner account in the correct organisation. Forwarding the link does not grant review access.
4. The reviewer makes a Keep or Remove decision for every role. Tenaxis rejects incomplete decisions, duplicate item IDs, expired submissions and replay.
5. If administrator approval is configured, decisions wait for approval.
6. Remediation removes the selected group roles, reads Microsoft state back and records the outcome. The last known live group owner cannot be removed.
7. A failed removal remains a remediation failure, with the role cache retained. It must be investigated and retried; it is not a completed successful review.

Evidence includes authenticated account ID, UPN when available, Entra sign-in method, submission time, role decisions, remediation errors and verification time. It identifies the account used, not the physical person operating the account. The old tenant-wide shared-link OTP and delegation flow are no longer supported.

When a reviewer cannot sign in

Microsoft Entra sign-in is the only default route into a review. For a reviewer who genuinely cannot sign in, an administrator can grant an e-mail one-time code fallback for one specific review. There is no tenant-wide setting: a single switch would weaken every review at once.

• Only a recorded owner of that review can be granted the fallback.
• The code is sent to the address recorded at grant time and nowhere else.
• Six digits, valid 15 minutes, single use, three attempts before it is burned.
• Granting and revoking are both recorded in the audit log.
• Concurrent verification attempts share the same database-enforced three-attempt allowance. A correct code can issue at most one session; verification and its audit event commit together.
• A verified OTP session lasts at most 20 minutes and applies only to this review and its recorded recipient. Granting again (including reassignment), revoking, or sending a new code invalidates previous OTP sessions. The review deadline and status still apply.
• Submission rechecks the current grant while saving decisions. If revocation commits first, the old session cannot submit. Revoking after a submission has committed does not undo that submission or completed Microsoft changes.
• If another request replaces or consumes the code during verification, the request is rejected without a session. Use the latest code or request a new one. A resend starts a new three-attempt allowance; existing rate limits still apply.

A review completed this way is recorded with authentication method EMAIL_OTP rather than MICROSOFT_ENTRA, and exports carry that distinction, because a code sent to a mailbox proves control of that mailbox rather than the directory identity. Treat it as weaker evidence than a signed-in review.

Current membership and historical review evidence serve different purposes: subsequent membership changes do not rewrite a completed review snapshot. See Security & Permissions for scope and retention.