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 onlyWhere the strongest restrictions live
- iOS 18Where the Apple Intelligence controls start
- AutomaticADE-enrolled devices arrive supervised
- 30minManaged-client response SLA
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.
Eight things that decide whether your restrictions actually apply.
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.
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.
Four things that stop a restriction policy being decorative.
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.
Three phases across roughly three to five weeks.
- 01Week 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
- 02Week 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
- 03Weeks 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
Six situations where supervision is the deciding factor.
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.
What you can actually control, by device posture.
| Feature | Supervised, corporate owned | Enrolled but not supervised | Unmanaged |
|---|---|---|---|
Supervised only restrictions apply | Yes | No | No |
Apple Intelligence features controllable | Yes | No | No |
App usage restricted to a list | Yes | No | No |
iCloud Private Relay preventable | Yes | No | No |
Apps prevented from being hidden | Yes | No | No |
Configuration and app deployment | Yes | Yes | No |
Supervision disclosed to the user | Yes | Not applicable | Not applicable |
Appropriate for personally owned devices | No | Yes | Yes |
How it is achieved | ADE, or Configurator with an erase | Profile or account enrolment | Nothing |
Suitable for frontline and shared devices | Yes | Partially | No |
Supervised only restrictions and where they start.
| Restriction | From | What it does | |
|---|---|---|---|
| Allow writing tools | iOS 18 | Prevents Apple Intelligence writing tools | |
| Allow Image Playground | iOS 18 | Prevents users from using Image Playground | |
| Allow Safari summary | iOS 18.4 | Prevents summarising content in Safari | |
| Allow Mail smart replies | iOS 18.4 | Prevents smart replies in Mail | |
| Allow Apple Intelligence reports | iOS 18.4 | Prevents Apple Intelligence reports | |
| Allow external intelligence integrations | macOS 15.2 | Prevents cloud-based intelligence services with Siri | |
| Allow apps to be hidden | iOS 18 | Prevents users from hiding apps | |
| iCloud Private Relay | iOS 15 | Prevents the user turning on iCloud Private Relay | |
| Allow App Clips | iOS 14 | Users cannot add App Clips, existing ones are removed | |
| Restrict app usage | iOS 9.3 | Approved or disapproved list beyond Settings and Phone |
Five steps, and the first one usually explains the problem.
- 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
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
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
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
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.
What Indian organisations ask about supervised restrictions.
Twelve questions to answer before you write the restriction policy.
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.
The pages around this one.
Zero-touch Apple deployment
The route that supervises devices automatically, starting at the purchase order.
Learn moreAccount-driven User Enrolment
The right model for personally owned hardware, where supervision does not belong.
Learn moreiPhone and iPad management
The wider iOS and iPadOS management picture: enrolment models, BYOD and kiosk deployments.
Learn morePick 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.