Skip to main content

We have a requirement to use a exam application for proctored exams through Proctorio on iPads.
Our specific need is:
• Enable camera access exclusively for this exam application.
• Currently, we have disabled the camera from the profile side to prevent other apps from accessing it.
We need a solution that:
• Allows the exam application to record via camera,
• While keeping the camera disabled for all other applications.

Unfortunately this is an Apple limitation. You can either allow users to accept camera allotments or not and it will pop up for each app once requested. The TCC in this case is user based and is either allow users to accept or you can decline it completely. 
 

Again, an Apple limitation at this point. We did push for TCC application granularity in our roundtables at JNUC though. 


Apple released a new camera restriction late in the iOS 26 beta cycle for allowing exceptions to the camera restriction. It will allow administrators to exempt apps from the allowCamera restriction by specifying their bundle IDs.

Keep in mind this is only for iOS 26+ and it requires using blueprints. It may not be useful for you today, but it’s there when you’re able to upgrade your devices.

My understanding is Jamf Pro blueprints should have already implemented this by now. I’m not sure about Jamf School, but it’s worth checking.

Create a new Jamf Pro blueprint and add the Restrictions component to the blueprint. Search for “camera” within the Restrictions component and look for allowedCameraRestrictionBundleIDs. You’ll need to enter the bundle ID of the app you want to exempt from the camera restriction.

Update: Unfortunately, doesn’t appear the Restrictions component is available yet in Jamf School blueprints.


Apple released a new camera restriction late in the iOS 26 beta cycle for allowing exceptions to the camera restriction. It will allow administrators to exempt apps from the allowCamera restriction by specifying their bundle IDs.

Keep in mind this is only for iOS 26+ and it requires using blueprints. It may not be useful for you today, but it’s there when you’re able to upgrade your devices.

My understanding is Jamf Pro blueprints should have already implemented this by now. I’m not sure about Jamf School, but it’s worth checking.

Create a new Jamf Pro blueprint and add the Restrictions component to the blueprint. Search for “camera” within the Restrictions component and look for allowedCameraRestrictionBundleIDs. You’ll need to enter the bundle ID of the app you want to exempt from the camera restriction.

Update: Unfortunately, doesn’t appear the Restrictions component is available yet in Jamf School blueprints.

According to the Apple reps in the JNUC roundtable, this isn’t available at this time. 🤷‍♂️


It’s available now from Apple. It’s just not implemented in Jamf School, unfortunately.

Starting at line 1269: https://github.com/apple/device-management/blob/release/mdm/profiles/com.apple.applicationaccess.yaml


I use Jamf School, over 100 locations, tens of thousands of users and devices.  It depends on how many of these you need.  If you can have someone send you a list of serial #s, make a static group, exclude that from the scoping on the rest which pushes the camera restriction.  Or, make a smart group which uses the application as the scoping, then add that as an exclusion to the other rules (I’m assuming these are all using device groups and mostly smart ones).

Jamf School’s Inventory searches have missing criteria, the way around that to see things you can’t otherwise is with smart groups scoped on those - who has what application installed is one of those and one I use for other things.

In my environment, I require people be authenticated to use the camera, until then it’s blocked (shifting device groups with overlapping different restrictions - Jamf School uses implicit deny, standard in IT, so No always wins, you have to move whichever set of iPads out of the No scope).  It’s been years.  I still get work orders complaining the camera doesn’t work and invariably it’s because no one logged in.