Meeting invitations: check which session was authorized
An invitation can lead to an access decision its recipient did not expect to make. Connect the presented task to the session actually authorized before accepting the workflow.
Читати португальськоюBy Pentesty
The case prompting the review
Huntress described an October incident where a fake scheduler presented a device code as a booking reference. Entering it on Microsoft’s legitimate page authorized the attacker’s session. The team reported containing the incident.
The organizational task is to make the access decision understandable within the workflow. A recipient may only intend to arrange a conversation. Assess whether they can recognize a change of context before approving access. Use the report to choose questions and criteria; the published occurrence does not itself describe the controls operating within your environment or their effectiveness.
Map legitimate use before blocking
Microsoft recommends assessing device code flow usage and restricting it to necessary, documented cases. Its policy procedure begins in Report-only and calls for impact assessment before enabling blocking. Emergency-access exclusions require review.
Ask teams to identify processes depending on this method, their owners and available alternatives. Include support and operations: an undocumented dependency may surface only when policy changes. Record its purpose, population and interruption cost, so the access decision considers the work that needs to remain possible. Assign someone to resolve uncertainty before that dependency is included in a broader enforcement change.
Connect intent, request and session
Build a procedure around three records: the task someone began, the access request presented and the session observed by the identity team. Use an artificial invitation within the laboratory and inform participants about the exercise’s purpose. The outcome should support comparison across those stages without exposing employee accounts or data or creating an unexpected authorization outside the agreed assessment.
Agree with the test user on pausing before approving an unexpected code. Ask how they would verify the request through a known contact. Observe whether the support procedure addresses that particular situation or simply repeats general instructions. Record the difficulty and propose a change the process owner can explain, maintain and incorporate into the ordinary path for obtaining help.
Accept policy using allowed and denied cases
Select an approved process that needs to keep working and another case that should be denied. Ask the administrator to record configuration, population and policy mode during each execution. Compare the visible result with the corresponding identity-provider event. A configuration screenshot alone does not represent all applications or groups, and the final decision should state the sample actually assessed.
Where an exception is necessary, assign its owner, purpose and expiry. Repeat the permitted case after applying it and observe whether other cases remain restricted. Reassess when a person changes role or a service is retired. The exception inventory should make it possible to end an authorization that has lost its purpose, with suitable communication to affected teams before removal.
Prepare for a report from an actual user
Support needs a straightforward route for reporting an unexpected approval. Agree on the information to collect, its recording location and who can assess the access. Avoid requesting passwords or active codes in support tickets. Preserve times, the context presented to the user and references to available administrative records, so the response team can connect the report to its own evidence.
Closing the exercise requires a decision about the workflow, exceptions and experience of people requesting help. Document tested cases and sample limits. Schedule another review when applications, populations or authentication methods change. The objective is to make authorization verifiable in everyday work and allow another owner to repeat the assessment using the same criteria, rather than relying on undocumented expectations.
Frequently asked questions
Should the exercise send actual phishing messages?
Use a laboratory with informed participants and synthetic accounts. This proposed procedure does not require campaigns against employees or contact with third parties.
What is the main acceptance evidence?
Connect the initial task, presented request and observed session. Record policy, population and outcome for every case included in the sample.
How should an exception be accepted?
Document its purpose, owner and expiry. Check the allowed case and repeat cases that should remain denied before accepting the change.
When should the procedure be reviewed?
Reassess after application, audience or authentication changes and when a dependency is retired. Preserve the sample to compare subsequent outcomes.
Sources and references
Original Pentesty analysis, published November 13, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.