Start with your known support route
A caller says they are from IT and asks you to open a remote support tool. Before discussing which button to press, establish whether this is the support interaction you requested. Our recommendation is to use the contact route your organisation has already published, rather than a number or link supplied by the unexpected caller.
Microsoft advises allowing a Quick Assist helper to connect only when you initiated the interaction by contacting Microsoft Support or your IT support staff directly. For a business, turn that advice into a procedure colleagues can actually follow: make the support contact easy to find and explain what an expected session looks like.
Explain the access before asking for it
Microsoft describes separate consent steps for screen sharing and a later request for control. Your support instructions should explain the task being investigated before asking the colleague to accept either. Use the remote tool approved by your organisation; this briefing is not a recommendation to introduce Quick Assist into every environment.
For a fictional engineering office, a colleague reports a printing problem through the normal support portal. When the assigned technician follows up, the colleague confirms the session through that established route. They agree to demonstrate the problem using a harmless test document and close unrelated material before sharing. The example illustrates a support process, not a claim that this sequence guarantees safety.
Practise the pause, not just the connection
In an agreed training exercise, ask a colleague what they would do if the requested access did not fit the reported problem. They should be able to pause and reach the support owner without being pressured to approve another prompt. Make that acceptable behaviour explicit in the team’s support guidance.
Microsoft warns against sharing credentials and says to disconnect immediately if you suspect the person connecting is malicious, then report the concern to relevant IT staff and/or local authorities. Keep a clear incident-reporting route alongside your routine support contact. Do not ask someone to continue a suspicious session while searching for a ticket number.
Give the team a short, usable instruction
Write a brief internal note naming the approved support channel and remote tool, with an example of how to verify a follow-up. Include what to do when a caller creates urgency or asks for something outside the agreed task. Let the support team check the wording against its real operating process before distributing it.
Test the note with someone who did not write it. Can they find the contact route and explain when to stop? Record any ambiguity and give its correction to an owner. Keep the guidance available somewhere colleagues can reach when the computer needing help is not working; a policy buried on that device is a poor starting point for the exercise.
Sources
Practical suggestions in this article are editorial recommendations. The source supports the guidance attributed to it.
- Microsoft Learn · Quick Assist ↗
Checked 20 October 2026
Something needs correcting?
Get in touch to explain which claim needs attention and share the supporting source.