June 17, 2026 - Enhanced access control and permissions for LWM2M service

Context


Change Type: Feature
Product area: Device management & connectivity
Component: LWM2M
Deployed at: eu.latest.cumulocity.com, apj.cumulocity.com, jp.cumulocity.com, cumulocity.com, us.cumulocity.com

Technical details

Build artifact: lwm2m-agent (1022.3.0)
Internal ID: DM-5341

Description


To improve security for the LWM2M service, stricter access control has been enforced. To work with device-specific LWM2M configurations from the Device Management application, users must now be granted explicit LWM2M ADMIN and READ permissions. This affects Device settings, Connectivity, Bootstrap, and more under the LWM2M Configuration tab, the device registration, and Device protocols at the tenant level. Administrators can assign the necessary permissions to users in Administration > Accounts > Users > Roles.

This seems like a breaking change, in that user and microservice roles will need to be updated to continue operating as before. When will this change be introduced so that we can schedule the updates?

This depends on which environment you are.

According to version number it is already rolled out to eu-latest, apj, jp, cumulocity.com and us.cumulocity.com

@Elias_Weingartner @Ozge_Akin do you know more you can share?

With this change, we’ve aligned a very few internal endpoints of the LWM2M REST API. There is no impact on ordinary users with regular inventory permissions; these roles are not mandatory as of now.

Thanks for the response, Elias. However, your statement seems contradictory to this announcement in the change log, as I understand it.

To be clear, we have users and microservices that access various endpoints on the /service/lwm2m-agent/* API, e.g. to read and edit LwM2M device configuration, to register LwM2M devices, and to add LwM2M device protocols (DDF XML definitions).

  1. Which permissions are required to be able to perform the above operations?
  2. Will the permissions required change as a result of this announced change?
  3. What are the permissions ROLE_LWM2M_READ and ROLE_LWM2M_ADMIN for?

Hi Martin,

apologies for the confusion this may have raised. With this change, we simply aligned the authorization for LWM2M rest endpoints. Please also note that the /service/lwm2m-agent endpoints are meant only for the use by the LWM2M UI and not customer microservices. We won’t block you from doing that, but we do not guarantee backwards compatibility on these REST APIs.

To answer your question:

  • Read-Only endpoints on this API (for example for Object Mappings) require either “INVENTORY_READ”, “LWM2M_READ” or "LWM2M_ADMIN "
  • Endpoints changing data (for example on Object or Resource Mappings) require “INVENTORY_CREATE”, “INVENTORY_ADMIN” or “LWM2M_ADMIN”

The inclusion of the regular inventory in the permission set roles makes this change well transparent to existing users.

The motivation behind this step is that we consider moving to domain specific roles such as “ROLE_LWM2M_READ” at a later point in time. Such a change indeed would be a massive breaking change. No decision has been taken yet here, and if we decided to do that, a corresponding announcement would be made with sufficient lead time.

Hope this helps,

Elias

Thanks for the update, Elias. That makes more sense. So, we could migrate to the domain-specific permissions now or leave the inventory permissions until such time as you announce the breaking change.

Regarding the LwM2M REST endpoints, we use a microservice to help the user register devices and configure them in a consistent manner, as the user does not have the knowledge to use the device registration form. We have developed this against this description: LWM2M - Cumulocity documentation.