Should a cloud tenant block end-user consent to third-party applications outright, or restrict it?
answer
- remove the step nothing can substitute
- blocking moves the cost onto people
- unstaffed queues cause circumvention
- verified publishers plus a narrow scope set
- who is allowed to say no
basics
~20 sRestricting usually beats blocking. Blocking removes the step an operator cannot substitute but sends every legitimate integration to a queue somebody must staff; the workable middle allows a narrow, low-risk scope set and adjudicates the rest.
solid answer
~50 sStart from what the technique requires: somebody with authority must press Accept. The operator can change the application name, the pretext, the sender and the timing, but cannot substitute that step, which is why the consent policy is the control that actually bites rather than another awareness campaign. Blocking end-user consent outright removes it, and the cost is organisational, not technical: every legitimate integration becomes a request that an administrator must judge, and if nobody owns that queue with a credible turnaround, people route around it into personal accounts and unmanaged tenants and you have traded a visible risk for an invisible one. The usual defensible position is a narrow allowance — consent permitted only to applications from known publishers and only within a low-risk scope set, everything touching mail, files or directory data going to a request queue with an owner and a stated turnaround. The decision you are really making is who staffs that queue and what delay the business will accept.
go deeper
Know that end-user consent is a setting an organisation can turn off, and that doing so means someone else must approve applications instead. You are not expected to weigh the tradeoff.
Explain why the consent decision is the control point: the operator can vary everything about the lure except the requirement that somebody approves it.
Argue for the restricted middle position concretely — which scope set stays self-service, which goes to a request, and how you would handle the grants that already exist.
Own the organisational half: name the team that staffs the queue, the published turnaround, the written grounds for refusal, and the signal that tells you people have started routing around the policy.
## Frame it as removing a required step The consent lure has one step the operator cannot buy their way around: a principal with authority must approve the request. Everything else is fungible. The application name changes for free. The pretext changes for free. The sending identity changes for free. The tenant it is registered in changes for free. But if nobody in your directory is permitted to consent, the technique has nowhere to land. That is what makes consent policy a control class rather than a hardening tweak, and it is the reason "train the users harder" is a weak answer: training reduces the hit rate on a step that only has to succeed once. ## The three positions, and their real costs **Leave end-user consent open.** Zero friction, and every integration a team wants just works. The lure is fully available, and its success is bounded only by how many people receive it. Defensible only in a very small organisation where any grant would be noticed by the person who runs everything. **Block it outright.** The technique is removed. The cost lands on people, not systems: every legitimate integration — a scheduling assistant, a survey tool, a developer's own script — becomes a request an administrator must adjudicate. The failure mode is well documented and predictable. If the queue has no owner and no stated turnaround, the requests do not stop; they migrate. Work moves to personal accounts, to a departmental tenant nobody registered, to a copy of the data in a spreadsheet. You will have removed the lure from a surface you can see and pushed the same business need onto surfaces you cannot. **Restrict it.** Permit consent only to applications from publishers that have been verified through the platform's publisher-verification path, and only for a scope set you have decided is low risk — typically a basic profile read and nothing that touches mail, files, or directory data. Everything else becomes a request. This keeps the long tail of harmless integrations self-service, which is what protects the queue from becoming the bottleneck that drives circumvention, while the scopes an operator actually wants are the ones that always require a human decision. Most organisations land on the third position, and an interviewer is listening for whether you can say *why* rather than which one you picked. ## The parallel decision for the device-code flow The same reasoning applies to the cross-device flow. There is no stronger factor to deploy, because the strongest one is already being presented correctly. The lever is availability: permit the device authorization flow only where it is genuinely needed — the shared terminals, the warehouse scanners, the meeting-room devices — and refuse it everywhere else. The organisational catch is identifying those genuine cases before you switch it off, because the ones you miss are usually operational technology owned by a team that does not read your announcements and will discover the change at the worst moment. ## What you must be able to answer when you propose it This is where the decision stops being technical. - **Who owns the queue?** A named team, not "IT". If the answer is an alias that three people watch when they can, the policy will erode. - **What is the turnaround, and is it published?** A one-day published turnaround with occasional misses beats an unstated best-effort. People plan around latency they can predict. - **Who can refuse, and on what grounds?** Somebody will eventually be told no for a tool a senior leader has already bought. If the grounds are written down beforehand, that is a policy conversation; if not, it is a personality conversation and the policy loses. - **What happens to the grants that already exist?** A tightening changes the future. The existing population was granted under the old rules and has to be dealt with as its own piece of work. - **How will you know the queue is failing?** Rising request volume is healthy. Silence combined with new integrations appearing in the business is the signal that people have gone around you. ## The measure of success is not zero grants A tenant with no third-party grants at all is usually one where the work moved somewhere else. The honest target is that grants carrying meaningful scopes were each approved by someone accountable, and that the self-service path is wide enough that nobody needed to invent a workaround. ## Common wrong answers - "Block it, obviously." Correct on the technique, silent on the queue that decides whether it survives contact with the business. - "Educate users to check what they are approving." Reduces the rate on a step that needs one success. - "Require MFA before consenting." The user already authenticated correctly; the factor was never the weak point. - "Review the grants regularly." A worthwhile hygiene habit, and a detective measure that arrives after the mail has been read.
- Why is user education a weak answer to this technique?Because the lure needs one success and education only lowers the rate. It is also asking users to distinguish a legitimate consent screen from a malicious one when both are rendered by the genuine identity provider and differ only in the application's name and requested scopes. That judgment is hard for practitioners, let alone everyone.
- You block end-user consent and nobody complains. Is that a good sign?Usually not. Legitimate integration demand does not vanish on a policy change. Silence combined with new tools visibly appearing in the business suggests the work moved to personal accounts or an unmanaged tenant. Healthy adoption looks like a steady request queue, not an empty one.
- Does restricting consent to verified publishers close the technique?It narrows it substantially rather than closing it. Publisher verification raises the cost and the traceability of registering the application, which matters against opportunistic operators. A determined crew can still work within the allowed scope set or target someone who can grant beyond it, so keep the high-value scopes behind a human decision.
saying these in an interview costs you the question
- Picks block or allow without naming the operational cost
- Proposes user training as the primary control
- Assumes stronger authentication would remove the technique
- Leaves the approval queue with no owner or turnaround
- Treats zero third-party grants as the success measure
- Forgets the grants that already exist under the old policy