What is delegated access?¶
Delegated access allows one account, user or application to act with permission on behalf of another account or resource.
It is commonly used for shared mailboxes, assistants, team files, support staff and connected applications.
What this means in practice¶
A delegate may be allowed to read messages, send email, manage a calendar, edit files or administer parts of an account. The scope depends on the permissions granted.
Delegation may be created by the user, an administrator, a group policy or an application-consent process. It may be temporary, permanent or inherited through group membership.
For investigators, identify who granted the delegation, when it became effective, what permissions it allowed and whether it was active at the time of the event.
Delegated access can also be abused. An attacker or compromised administrator may grant hidden access that survives a password reset.
Use precise language. Distinguish the owner of the resource from the identity that actually performed the action.
What this may show¶
Some cloud logs record both the resource owner and the delegate. Others may show only the account or mailbox against which the action occurred. This can make activity appear to come from the owner when another authorised identity performed it.
What this does not show on its own¶
The dangerous assumption is that activity attributed to the resource owner must have been carried out by that owner.
What to do next¶
Obtain role-assignment and administrator records where available. Compare the action with the delegate’s own login, session, device and IP records.
Do not treat all delegated activity as unauthorised. It may be a normal business process. The question is whether the delegate had authority and whether the recorded action falls within that authority.
Key takeaway
Delegated access separates ownership from action, so establish who held the permission, who used it and what the delegation allowed at the relevant time.