Skip to main content
Supervised restrictions, India

The Apple restrictions you actually want are supervised only. Are your devices supervised?

A supervised device is one the organisation owns, and that posture opens up controls ordinary enrolment never reaches: the generative feature switches, approved application lists, iCloud Private Relay and a good deal besides. What happens in a lot of Indian estates is that somebody configures exactly those settings, observes no change whatsoever on the handsets, and concludes the management platform is broken. It rarely is. Delivered remotely from Gachibowli, Hyderabad.

Supervised Apple device restrictions for Indian organisations
  • Supervised onlyWhere the strongest restrictions live
  • iOS 18Where the Apple Intelligence controls start
  • AutomaticADE-enrolled devices arrive supervised
  • 30minManaged-client response SLA
The failure mode

A restriction policy that looks configured and enforces nothing.

The difficulty with this particular problem is that the management console looks entirely healthy throughout. Nothing short of picking up a handset will reveal it.

  • The sequence begins normally. A policy gets written, the platform raises no objection, and the assignment shows as complete. Every signal available to an administrator agrees the control is live, and not one of those signals has consulted a device.
  • Meanwhile the handset carries on exactly as before. The setting needs supervision, the handset does not have it, and so the instruction is discarded. Nothing is logged. Nothing is flagged. A control your organisation is counting on does not exist and nothing anywhere says so.
  • These gaps live for years, because who goes back and tests a restriction nobody imagined could fail. Discovery tends to happen during a security incident or partway through an audit, which are comfortably the two worst occasions to learn that a control was ornamental.
  • Proving it either way takes about five minutes. Choose a single restriction you are confident is in force and go and look for it on a real handset. Where it is absent, supervision is nearly always the explanation, and the remedy belongs to enrolment rather than to policy.
What supervision means

Eight things that decide whether your restrictions actually apply.

What makes this area odd is the shape of the failure. Your console takes the policy, marks it assigned, raises nothing, and out on the handset the setting is simply disregarded. Grasping how supervision works is the whole difference between a policy that binds and one that merely reads well.

Supervision reflects ownership

The published definition ties supervision to organisational ownership of the hardware, with the extra configuration and restriction authority following from that. Read it as a claim about who owns the device before you read it as a technical mode. That ordering explains precisely why it suits company-issued equipment and does not belong anywhere near a member of staff own handset.

Some restrictions exist only under supervision

A subset of the restriction catalogue requires both enrolment and supervision, and the documentation says so directly. Write a policy that assumes one of those will take effect on a device lacking supervision and it fails without producing an error, a warning or any other signal. Gaps that announce themselves are manageable. This kind is not.

The Apple Intelligence controls are supervised only

Two arrived with iOS 18, covering writing tools and Image Playground. Three more followed in iOS 18.4, covering Safari summaries, smart replies in Mail, and the Apple Intelligence reports. Over on the Mac there is a further one from macOS 15.2 that blocks external cloud intelligence services working with Siri. Lose supervision and you lose the ability to take any of those decisions.

Automated Device Enrollment supervises automatically

Come in through the automated route and supervision is simply part of the outcome, with no additional action required, across every current Apple platform. This is the path without friction, and it is the entire reason getting hardware registered to your organisation at the moment of purchase carries so much weight.

Apple Configurator supervises, but erases

The manual route exists for iPhone, iPad and Apple TV, using Apple Configurator on a Mac, and it demands a cable and wipes the device on the way through. Which means adding supervision to hardware that people are using every day in your Hyderabad or Pune office is a disruption rather than a background change, and the sensible answer is usually to wait for the refresh cycle.

The user is told, in plain language

Open Settings on a supervised handset and the device says so, naming the organisation and stating that it can watch internet traffic and find the device. Disclosure is deliberate here, not incidental. Worth understanding before an employee reads that sentence with no prior warning and the matter lands on someone desk in HR.

App usage can be restricted to a list

There has been a control since iOS 9.3 that puts everything except Settings and Phone onto either an approved or a blocked list. Where a device exists to do one job, think delivery handsets, a billing counter, tablets carried by field surveyors, this single restriction is what actually defines the purpose of the hardware.

Availability varies by management platform

Not every restriction shows up in every management service, and a service is free to alter the default state of any of them. So the question of whether Intune, Jamf or something else surfaces a particular setting has to be answered against the console you actually run and then proved on hardware. The published list on its own settles nothing.

The current question

Most Indian organisations asking about supervision this year are asking about Apple Intelligence.

Generative capability landing on staff handsets created a governance problem for a lot of boards, and every lever that answers it sits on the supervised side of the line.

  • Two controls shipped in iOS 18. One suppresses the writing tools, the other suppresses Image Playground. Both need supervision, which means an unsupervised fleet cannot apply either of them regardless of what the policy says.
  • A further three landed in iOS 18.4. They cover summarising content inside Safari, the smart reply suggestions in Mail, and the Apple Intelligence reports feature.
  • The Mac has its own, available since macOS 15.2, which stops external cloud intelligence services being used through Siri. If what worries you under the DPDP Act is client material or internal documents being handed to a model you do not run, that is the one to read carefully.
  • None of the above argues that these features ought to be disabled. The argument is that the choice should belong to you and be written down somewhere. Without supervision you do not get to make it either way.
Ask us about the AI feature controls
How we approach it

Four things that stop a restriction policy being decorative.

Because nothing announces itself when this goes wrong, each part of our method exists to drag enforcement into view. Establish supervision before anything else, take the decisions consciously, prove them on hardware, and tell you plainly what retrofitting will cost.

We confirm supervision before writing policy

Part of the restriction catalogue demands both enrolment and supervision. So the opening task is working out which of your devices genuinely hold that posture and how they came to hold it, since that answer sets the outer boundary of what any policy you write is capable of expressing.

We treat the Apple Intelligence decision as governance

Every one of those features can be switched off, and every one of them requires supervision to do it. Where the DPDP Act applies, the question of whether company or client material is handed to a model you do not operate is something to decide on purpose and minute, rather than something to inherit from whatever the platform shipped with.

We verify on device, never in the console

Since management services do not all expose the same restrictions, a setting your console omits, or one the installed release is too old for, yields a policy that reads perfectly and binds nothing whatsoever. That is why nothing we apply is signed off until somebody has looked at it on actual hardware.

Remote-first, and honest about the retrofit cost

Bringing an existing handset under supervision through Configurator means a cable and a wipe. When the unsupervised population is out there being used every day, the honest recommendation is almost always to catch it at the next refresh instead of erasing equipment that is working fine. The engagement itself runs remotely from Gachibowli in Hyderabad, and managed clients hold a 30 minutes response SLA.

How an engagement runs

Three phases across roughly three to five weeks.

Duration comes down to one variable: the size of the population that is unsupervised and simultaneously in active daily use, because bringing those under supervision through Configurator wipes them.
  1. 01
    Week 1· Week 1

    Establish supervision state

    We sort the estate into supervised and unsupervised and establish how each device arrived in its current state. Anything that came through the automated enrolment route is already supervised. Everything else faces either re-enrolment or a wipe via Configurator, and the ratio between those two groups determines what the rest of the plan looks like.

    • Supervised and unsupervised populations identified
    • Enrolment route documented per population
    • Devices requiring an erase to supervise listed
    • OS version spread recorded against restriction floors
  2. 02
    Week 2· Week 2

    Decide the restriction policy

    We work through which of the supervised restrictions you genuinely want, writing down why in each case. For most Indian clients at the moment the generative feature switches take up the bulk of that discussion, and they warrant an actual decision rather than whatever the platform happens to default to.

    • Restriction policy drafted with rationale per setting
    • Apple Intelligence position decided explicitly
    • App usage approach agreed for frontline devices
    • Availability confirmed against your management platform
  3. 03
    Weeks 3-5· Weeks 3-5

    Apply, verify and communicate

    Each restriction goes out and is then confirmed on physical hardware instead of in the console, because a setting your platform never surfaces, or one the installed release predates, fails without saying anything. Staff get told what is happening, which is sensible given that the handsets disclose supervision in Settings regardless.

    • Restrictions applied and verified on device
    • Version floor exceptions documented
    • User communication issued about supervision
    • Review cadence agreed as Apple adds restrictions
Where this matters

Six situations where supervision is the deciding factor.

What these six have in common is an organisation that went looking for one particular control, discovered it was real and documented, and then discovered their own hardware was in no position to accept it.

A regulated firm restricting generative features

Lenders, insurers, NBFCs and anybody operating under client confidentiality obligations increasingly need a say in what material a generative feature is allowed to see. All the levers that give them that say require supervision, including the macOS one that shuts off external cloud intelligence services reached through Siri.

A retail estate locking devices to a task

Everything beyond Settings and Phone can be placed on an allowed or a blocked list. Take an iPad sitting on a billing counter, or a handset carried round stores for surveys: it exists to run one application, maybe two. That restriction is the entire distinction between a work tool and a general purpose device somebody happens to use for work.

A school or ed-tech deployment

Education standardised on supervision long ago, and the reason is straightforward: everything worth controlling on a student device sits in that half of the catalogue. Hardware coming through the automated enrolment route already holds the posture, which is why getting registration right at purchase does more for you than any amount of classroom policy.

An organisation that cannot prevent hidden apps

Since iOS 18 there is a switch that stops people concealing applications on their home screen. If your support team or your compliance position depends on being able to see what is actually present and visible, you need it, and you can only have it under supervision. Most estates find this out at an inconvenient moment.

A business that needs iCloud Private Relay off

There has been a restriction since iOS 15 that stops a user enabling iCloud Private Relay. Where your web filtering, your data loss prevention tooling or your CERT-In logging obligations all rest on being able to see traffic and attribute it to a person, this comes up constantly, and supervision is the price of admission.

A team whose restrictions appear to do nothing

By some distance the case we are called about most. Configuration correct, platform content, handset indifferent, and the explanation is always the same mismatch between what the setting requires and what the device has. Once somebody thinks to look at the hardware instead of the dashboard, the diagnosis takes a few minutes.

Three positions

What you can actually control, by device posture.

It is the middle column that causes trouble. From the console that estate presents as fully managed, while the settings you care about most are having no effect at all.
Feature
Supervised, corporate owned
Enrolled but not supervised
Unmanaged
Supervised only restrictions apply
YesNoNo
Apple Intelligence features controllable
YesNoNo
App usage restricted to a list
YesNoNo
iCloud Private Relay preventable
YesNoNo
Apps prevented from being hidden
YesNoNo
Configuration and app deployment
YesYesNo
Supervision disclosed to the user
YesNot applicableNot applicable
Appropriate for personally owned devices
NoYesYes
How it is achieved
ADE, or Configurator with an eraseProfile or account enrolmentNothing
Suitable for frontline and shared devices
YesPartiallyNo
A representative selection

Supervised only restrictions and where they start.

Drawn from the published supervised restriction documentation. Treat it as a sample rather than a complete catalogue, and remember that what your own management platform surfaces may differ.
RestrictionFromWhat it does
Allow writing toolsiOS 18Prevents Apple Intelligence writing tools
Allow Image PlaygroundiOS 18Prevents users from using Image Playground
Allow Safari summaryiOS 18.4Prevents summarising content in Safari
Allow Mail smart repliesiOS 18.4Prevents smart replies in Mail
Allow Apple Intelligence reportsiOS 18.4Prevents Apple Intelligence reports
Allow external intelligence integrationsmacOS 15.2Prevents cloud-based intelligence services with Siri
Allow apps to be hiddeniOS 18Prevents users from hiding apps
iCloud Private RelayiOS 15Prevents the user turning on iCloud Private Relay
Allow App ClipsiOS 14Users cannot add App Clips, existing ones are removed
Restrict app usageiOS 9.3Approved or disapproved list beyond Settings and Phone
How an engagement runs

Five steps, and the first one usually explains the problem.

When a client comes to us because their restrictions do not seem to be doing anything, the supervision audit resolves it inside the first hour, well before anyone opens a policy document.
  1. 1

    Audit supervision across the estate

    Week 1

    We establish the posture of every device and how it got there. The automated enrolment path confers supervision by itself across the current Apple platforms, and on the Mac side there are two further routes, account-driven and profile-based enrolment, that also produce a supervised machine from macOS 11 onwards.

  2. 2

    Map required controls against the supervised list

    Week 1-2

    Each control on your wish list gets three checks: does it demand supervision, from which release does it exist, and does your particular console actually offer it. Given that availability genuinely differs between management services, none of those three is taken on trust.

  3. 3

    Take the Apple Intelligence decision deliberately

    Week 2

    There are six switches across iOS and macOS, arriving in three waves. For each one you take a position, and each position is written down with the thinking behind it. That record is what allows the policy to survive a review a year from now, when nobody remembers the meeting.

  4. 4

    Apply and verify on real devices

    Week 3-4

    Every restriction is proved in force on real hardware, one device per platform and per release in scope. We do not skip this for anybody, because when it fails it fails quietly and looks precisely like success from where an administrator is sitting.

  5. 5

    Communicate and set a review cadence

    Continuous

    Staff are told what supervision means, which is only sensible when their handsets disclose it in Settings regardless. After that comes a review at each major release, because new supervised restrictions keep arriving and the genuinely useful ones are usually the recent additions. For managed clients this is simply part of ongoing operations, under a 30 minutes response SLA.

Straight answers

What Indian organisations ask about supervised restrictions.

Apple states that supervision generally denotes that the device is owned by the organisation, which provides additional control over its configuration and restrictions. It is a posture that reflects ownership, and it unlocks a specific set of restrictions that are unavailable to merely enrolled devices. The user can see in device settings that the device is supervised and by which organisation, so it is a disclosed state rather than a hidden one.

The most common reason by far is that it is supervised only and the device is not supervised. Apple states plainly that certain restrictions are available only for devices that enrol in a device management service and are supervised. The second most common reason is that your management platform does not expose the setting, since availability varies between services. Both are diagnosed the same way: check the restriction on an actual device rather than in the console.

Automated Device Enrollment supervises automatically, from iOS 13, iPadOS 13.1, macOS 10.14.4, tvOS 13, visionOS 3 and watchOS 10, which is why devices registered to your organisation at purchase arrive supervised with no extra work. iPhone, iPad and Apple TV can also be supervised manually using Apple Configurator for Mac, with the device physically connected and erased during the process. Macs on macOS 11 or later can additionally become supervised through account-driven or profile-based enrolment.

Through Apple Configurator, yes, but each device must be physically connected to a Mac and is erased during the process. For a population in daily use across Hyderabad, Bengaluru and Mumbai offices, that is a logistics exercise and a disruption, not a policy push. The realistic plan for most estates is to supervise at the next hardware refresh through Automated Device Enrollment, and to fix the procurement route now so every new device arrives supervised.

Yes, on supervised devices. Allow writing tools and Allow Image Playground are available from iOS 18, Allow Safari summary, Allow Mail smart replies and Allow Apple Intelligence reports from iOS 18.4, and Allow external intelligence integrations from macOS 15.2. On an unsupervised estate none of these controls can be applied, which means the organisation has no way to implement whatever position it takes.

It prevents the use of external, cloud-based intelligence services with Siri, and it is available from macOS 15.2. For organisations whose concern is corporate or client content leaving for a third-party model, a live question for anyone with DPDP Act obligations or client confidentiality terms, this is the specific control to evaluate.

Yes. Device settings display wording of the form that the device is supervised and the named organisation can monitor your internet traffic and locate this device. Supervision is disclosed by design rather than hidden, which is why we recommend telling staff before enrolment rather than letting them discover the wording themselves.

Yes, with Restrict app usage, available from iOS 9.3 on supervised devices. Any apps other than Settings or Phone on iPhone can be placed on an approved or disapproved list. For single-purpose devices, delivery handhelds, billing counters, survey tablets, this is the core control, and it is the reason those deployments require supervised, company-owned hardware.

Both are controllable under supervision. From iOS 15 a restriction prevents the user turning on iCloud Private Relay, which matters where your network filtering or traffic attribution depends on visibility. From iOS 18, Allow apps to be hidden prevents users hiding apps, which matters where support or compliance depends on seeing what is present on a device. Neither control reaches an unsupervised device.

Not necessarily. Apple states that not all restrictions are available in all device management services, and that services can change the default state for any restriction. What matters is what your platform exposes, verified on a device. That verification is built into our process precisely because the published Apple list and a given console do not always match.

No. Supervision denotes organisational ownership, so it belongs on corporate hardware. For personally owned devices the appropriate model is account-driven User Enrolment, which manages only the work portion and deliberately cannot reach the rest. Asking employees to accept supervision on their own phones is both inappropriate and, in practice, a fast way to sink a BYOD programme.

Scoped per engagement, by device population and how much of it is currently unsupervised, with a quote on request. The free first step costs you five minutes: pick one restriction you believe is applied and check it on an actual device. That single test tells you whether your Apple restriction policy is enforced or decorative. Enquiries get a reply within 4 business hours.
Policy checklist

Twelve questions to answer before you write the restriction policy.

Work through the first group before the others. Its answers decide whether anything below it is even possible.

Supervision

  • Are corporate devices supervised?
    Otherwise the supervised list does not apply.
  • Were they enrolled through Automated Device Enrollment?
    That supervises automatically.
  • Would supervising require an erase?
    Apple Configurator erases the device.
  • Are new devices registered at purchase?
    The clean route for everything after.

Apple Intelligence

  • Do we have a position on writing tools?
    iOS 18 and supervised only.
  • What about Safari summaries and Mail replies?
    iOS 18.4.
  • Do we want external Siri integrations off?
    macOS 15.2.
  • Is the estate on iOS 18 or later?
    The floor for these controls.

Operational

  • Does our platform expose these settings?
    Availability varies by service.
  • Have we verified on a device?
    Not just in the console.
  • Have users been told?
    Supervision is disclosed anyway.
  • Who reviews new restrictions?
    Apple adds them each release.
References

Official documentation

Next step

Pick one restriction you believe is applied, and check it on an actual device.

That single test tells you whether your Apple restriction policy is enforced or decorative. If it is not applying, supervision is almost always the reason, and we can tell you exactly what it would take to fix. Initial reply within 4 business hours.