Security policy update in IoT Hub blocks device registration from external provisioning service

IOT Microsoft Azure IoT
, , , , , , , ,
1

We recently updated our IoT Hub security policies to enforce stricter device authentication, and now all new device registrations through DPS are failing with 403 Forbidden errors. The issue appears related to IoT Hub IAM roles and DPS integration permissions, but I’m not sure which specific policy is blocking the registration flow.

Here’s the error we’re seeing:


HTTP 403: Forbidden
Error: Device registration denied
Policy: custom-security-policy-v2

Existing devices continue to work fine, but we can’t onboard any new devices. Has anyone encountered similar issues after updating custom security policies? We need to maintain our security requirements while enabling device registration.

2

Thanks for the suggestions. I checked the DPS managed identity roles and found it only had ‘IoT Hub Registry Contributor’. However, I’m still unclear about how the custom security policy interacts with these role assignments. Does the policy evaluation happen before or after the RBAC role check?

3

Based on the error pattern and the timing after your security policy update, here’s the comprehensive solution addressing all three focus areas:

IoT Hub IAM Roles: First, verify the DPS managed identity has the correct roles assigned:


az role assignment create --assignee <DPS-managed-identity-id> \
  --role "IoT Hub Data Contributor" \
  --scope /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Devices/IotHubs/<hub>

You need both ‘IoT Hub Data Contributor’ and ‘IoT Hub Registry Contributor’ for full device registration capabilities.

DPS Integration Permissions: Your custom security policy needs to explicitly allow DPS operations. Update your policy JSON to include:

{
  "properties": {
    "policyRule": {
      "if": {
        "allOf": [
          {"field": "type", "equals": "Microsoft.Devices/IotHubs/devices"},
          {"field": "identity.principalId", "equals": "<DPS-managed-identity-id>"}
        ]
      },
      "then": {"effect": "allow"}
    }
  }
}

Custom Security Policy Restrictions: The issue is that custom-security-policy-v2 likely has a broad deny rule that’s catching DPS registration attempts. You need to add an exception specifically for the provisioning service. Here’s the critical fix:

  1. Navigate to your IoT Hub policy assignments in the Azure Portal
  2. Edit custom-security-policy-v2
  3. Add an exemption for the DPS service principal before any deny rules
  4. Ensure the policy allows ‘Microsoft.Devices/IotHubs/devices/write’ action for DPS identity

The key is understanding the evaluation order: Custom Policy → RBAC → Resource-specific permissions. Your policy was blocking at the first gate, so RBAC roles never even got evaluated.

After making these changes, test with a new device enrollment. The 403 should resolve immediately. If you still see issues, enable IoT Hub diagnostic logs (category: DeviceIdentityOperations) to see the exact policy rule that’s triggering.

One more important note: If you’re using enrollment groups in DPS, make sure the custom policy allows bulk registration operations, not just individual device writes. This requires the ‘Microsoft.Devices/ProvisioningServices/enrollmentGroups/write’ action to be permitted as well.

4

I’ve seen this before. The custom security policy is likely overriding the default DPS enrollment permissions. Check if your new policy explicitly grants the ‘Device Provisioning Service’ managed identity access to register devices in IoT Hub. The policy might be too restrictive on the service principal level.

5

I’d recommend enabling diagnostic logs on both IoT Hub and DPS to see exactly which policy rule is triggering the 403. The logs will show the policy evaluation chain and which specific condition is failing. This will save you hours of guesswork.

6

The policy evaluation happens first, then RBAC. If your custom policy has explicit deny rules, they override any allow permissions from RBAC roles. Look for conditional access policies or resource-specific deny statements in your custom-security-policy-v2. Also, DPS uses a specific authentication flow that requires the ‘Microsoft.Devices/IotHubs/devices/write’ action - make sure that’s not blocked.

7

We had this exact problem last month. The issue was that our updated security policy didn’t include the IoT Hub Data Contributor role for the DPS service principal. When you create custom policies, you need to ensure the DPS managed identity has both ‘IoT Hub Data Contributor’ and ‘IoT Hub Registry Contributor’ roles. Also verify that your custom policy isn’t blocking the registration endpoint specifically. Check the policy JSON for any deny rules that might affect device provisioning operations.