The document describes the security-relevant settings of the LANCOM Management Cloud (LMC). It serves as a reference for the safe operation of the LMC.
In the LMC, we differentiate between three different account types:
Data is strictly separated per account and can be only accessed if an individual principal was granted a membership to access this particular account.
Accounts are ordered by hierarchy: a project needs to be created in an organisation, and organisations are created below distributions. There are some functions that allow managing projects from the parent organisation (e.g. administrator inheritance, device pools that can be used to assign devices to projects), which will be described further below.
Overall it is known best practice, to grant only the least rights to a particular principal, which this principal requires to fulfill a certain task in the application. In LMC context this means to only very carefully grant project administrator rights and apply an authority with less rights, whenever possible. The following authorities can be granted per account level:
For LMC managed principals one can be granted a different authority in each account it has access to. This applies also for IdP authenticated principals.
In case IdP authorization also gets configured and enabled for an account, authorities and resulting rights of a principal are derived by applying the roles that are assigned in the IdP (also see for section "IdP principal management"). This results in granting the same authority per principal per account level or no authority at all, but cannot result in being e.g. a project administrator in one project and hotspot administrator in a second project of the same organisation. When using IdP principal management, it is recommended to not use the invitation mechanism for assigning authorities to principals IdP authorized in context of that particular account. Explicitly inviting users will result in so-called "direct memberships" which will overrule access control by the IdP.
Administrator inheritance can be used to increase security and ease of management for Managed Service Providers, who usually have an organisation and use individual child projects for their customers. Instead of inviting principals to projects individually, and also managing these principals individually, administrator inheritance allows members of the organisation to access the child projects without being explicitly invited to each of them. This simplifies access control, since those principals can be centrally managed in the organisation (e.g. in case a principal leaves the company and is no longer allowed to access LMC accounts). It removes the need to create direct memberships per project for each of those principals affected, and thereby reduces effort to perform access control restrictions at project level.
Direct memberships by using explicit invitations and administrator inheritance can be used in mixed scenarios per principal and account, resulting in a single principal being granted project access with different rights via administrator inheritance then those being granted by accepting an invitation and having a direct membership created. In this case rights granted via direct membership win over inherited ones, which can result in a higher set of rights from project membership then given via administrator inheritance. That's why we recommend to only very carefully apply direct memberships administrator inheritance scenarios. As secure default, LMC administrator inheritance is disabled in organisations, and needs to be enabled by organisation administrators. When enabling LMC administrator inheritance, a project level authority for those principals must be selected, which will be applied to inherited principals for all projects of the organisation.
IdP administrator inheritance can be enabled separately from LMC administrator inheritance at organisation level. In context of IdP authentication it works as LMC administrator inheritance described above, but is limited to those principals who are IdP managed via a configuration done at this particular organisation. If IdP authorization in LMC gets enabled additionally, LMC authorities will be granted rights according to returned values from the IDP and group mappings done on IdP setup (more details see below.
It is possible for project administrators to separately opt out of both LMC administrator inheritance and IdP administrator inheritance by activating the according setting in the project settings. Any change of inheritance status will be shown in the organisation log. Both variants to opt out of administrator inheritance are not available in Telekom Schwestercloud, as specified by contract.
For the LMC we adapt general recommendations on how to choose secure, memorable passwords and what to avoid, like they e.g. are provided by Bundesamt für Sicherheit in der Informationstechnik:
Creativity is unlimited, but a person must be able to remember the password well. Helpful strategies include:
Using a sentence and taking only the first (or second or last) letter of each word.
Converting some letters into numbers or special characters.
Using an entire sentence as a password:
Stringing together several words separated by special characters.
Randomly choosing 5–6 words from a dictionary and separating them with spaces, which makes the password easy to remember and type, but hard to crack.
In general: the longer, the better. For a good password, length and complexity are crucial.
A short, complex password should be at least 8 characters long and contain four types of characters (uppercase and lowercase letters, numbers, and special characters).
A long, less complex password should be at least 25 characters long.
For Wi‑Fi encryption methods such as WPA2 or WPA3, the password should be at least 20 characters long, because offline attacks are possible there.
In principle, all available characters can be used (uppercase and lowercase letters, digits, special characters such as spaces, ?!%+…).
Not suitable as passwords are names of family members, pets, best friends, favorite stars, birth dates, and so on. Passwords should also not consist of common variants and repetition or keyboard patterns such as “asdfgh” or “1234abcd”.
It is to be avoided to simply add a few digits to the end of a password or to place one of the usual special characters “$, !, ?, #” at the beginning or end of an otherwise simple password.
It is recommended to use a password manager to manage different passwords well, and protect the manager with one strong password. This way, only the particular principal of a password manager space has to remember one good password and can still use very strong, unique passwords everywhere.
Language‑specific characters and umlauts such as “ä, ö, ü, ß, €, ¢” should be avoided, because they may not be usable or available with non‑German services and keyboards, or may be encoded differently.
In default configuration, LMC requires at least eight digit password length, including at least one number and one special character. It is strongly recommended to at least create a password according to the guidelines stated above. Additionally, the corresponding environment variable can be adjusted to enforce stronger principal passwords. This is recommended to be done for any private LMC installation. It is considered as good practice to choose different passwords for each principal per LMC instance, each matching recommendations mentioned in the above section.
In general it is highly recommended to not leave any remotely managed resource unprotected, i.e. to apply password protection whenever possible. When doing so, apply password security guidelines mentioned above whenever possible. In some cases a project wide password can be set for device configuration. We do not recommend to chose this option, and it should only be used if really needed. Having a different password per device is much more secure. If a common password for device configuration per account cannot be avoided, it is strongly recommended to at least choose a high security password for that option.
To add an additional layer of access control and security, LMC managed principals can enable second-factor-authentication (2FA) for their principal. The secret additionally provided gets generated as time-based one time password (TOTP). The shared secret used by the authenticator app for TOTP creation gets generated by LMC. This shared secret can be included in either an authenticator app on a mobile device, or password manager extension of a browser on any computer. The second option is recommenced only if an LMC principal can make sure to be the only one accessing this particular browser's password manager extension. Security measures to protect browser password manager extensions or mobile devices are not part of this documentation.
Some especially sensitive to security customers can enable an option for their project, which in consequence will require providing a 2FA prior to entering the project. Enabling or disabling 2FA restrictions for a project gets shown in the project log. LMC managed principals who are not able to provide a second factor or whose shared secret was created by a different software will not be able to enter these projects. Principals must create a separate TOTP generator for each LMC instance they have access to, since each LMC instance provides different shared secrets for each principal.
For IdP managed principals the IdP has to be configured according to company security guidelines. Secure IdP configuration guidelines are not part of this documentation. The LMC will not check MFA related values in the IDtoken provided, since good practice in industry considers IdP managed principals as secured enough to also enter most 2FA restricted resources. For LMC 2FA restricted resources project administrators can choose, whether to a) not put any access restrictions to a project, b) allow only LMC managed principals enter the project after issuing their personal second factor, or c) require an IdP login or providing a principal's personal second factor to access the account. The third option will allow entering the project to principals of all IdPs configured at the particular LMC instance, if they additionally have access permissions either by direct membership, or IdP authorization. For more details on IdP user management see for section "Alternative authentication methods".
To apply another layer of access control to resources with high criticality, more advanced security measures outside the LMC must also be taken into consideration. These are not subject of this documentation.
In LMC there are several types of API keys available, each type applies a different scope and purpose.
| SIEM API keys | Principal-bound single account keys | Principal-bound cross account keys | |
|---|---|---|---|
| Account scope | Single account | One account, including direct child accounts. | Selection of one, multiple or all accounts of a principal, also possible for sibling accounts. |
| Permissions | SIEM relevant APIs | All APIs allowed as specified by membership per account, including write options. | All APIs allowed as specified by membership per account, including write options. |
| Maximum lifetime | Unlimited, but regular rotation recommended | 1 - 3560 days, shorter-lived keys and regular rotation recommended. | 1 - 356 days, short-lived keys and regular rotation recommended. |
| Maximum number | One per project | Five per account per principal, 100 per principal in total. | Five per account per principal, 100 per principal in total. |
| Use Cases | Retrieve device logs of a single account for monitoring usage, querying a specific set of SIEM relevant APIs. | E.g. retrieve monitoring data of several child accounts; assign networks to multiple sites via API script; claim, license and assign devices to sites via API script; mass device configuration via API script. | E.g. retrieve monitoring data of several child accounts; assign networks to multiple sites via API script; claim, license and assign devices to sites via API script; mass device configuration via API script |
SIEM API keys (Secure Information and Event Management) can be issued to particular endpoints of the LMC an are intended only to gather information on certain events within a single account. Every other endpoint will return a speaking HTTP error when trying to access it with a SIEM API key, nor can those keys be used to do any write or delete operation. Only project administrators can be create or revoke SIEM API keys. Project administrators must ensure to rotate a project's SIEM API key(s) whenever a principal with access to a project's SIEM API key(s) has no longer access to that project (see for section "Offboarding").
Principal-bound API keys are bound to an individual principal and inherit or mirror that principal’s permissions within the LMC account a principal is about to access with that particular API key. They are ideal when actions must be attributable to a specific person (for audit, per-principal limits, or fine-grained authorization) or for personal automations that like scripts which call an API with certain principal's LMC account rights. Each principal typically has their own keys, visible and manageable only by that principal, which supports per-principal audit trails and easier incident response by revoking single principal key(s) instead of rotating a shared SIEM API key.
The scope of a principal-bound API key can be chosen on creation and either be limited to only one account (organisation or project, "Single account API key") or chosen for cross account access. Single account keys can include only one project or organisation they grant access to. Owning any principal-bound API key with access to an organisation with LMC administrator inheritance enabled will also allow principals who get inherited from an organisation to child projects to access all those child projects with an API key, whenever project administrators did not opt out of administrator inheritance. Cross account access keys may include a selection of sibling accounts, or all accounts a principal is member of, independent of their relation to a certain parent account. Due to their potential scope cross account keys must be created very carefully and stored securely.
The default number of principal-bound API keys is limited to 100 keys per principal, whereas the number of API keys per principal per project is limited to five.
Each principal-bound or SIEM API key generation or revocation gets logged in the accounts the key is able to access. In case of administrator inheritance it gets only logged in the organisation it is created or revoked for, but noch the child accounts. On any API key generation the key value itself gets displayed only once, so principals must make sure to immediately copy the key. If this is forgotten, principals can only revoke that particular key and create a new one. For each API key created, principals have to chose an expiry option for the key, depending on scope and usage:
Project administrators can choose to generally prohibit API key usage in the particular account they are responsible for. API keys cannot be newly created for accounts whose administrator opted out of API key access. Trying to access those accounts with a key which was created prior to restriction will result in an HTTP Status 403 error message (unauthorized). Every account access with any API key gets logged in the corresponding account log. Each management action which gets typically logged in an account's context is indicated as having been performed by an API key.
As of December 2025, API keys cannot be created by and used for IdP managed principals in LMC. If not forbidden by compliance requirements, a mixture of IdP- and LMC-managed principals per account is allowed by LMC's technology. In this scenario, LMC-managed principals with personal API keys can be utilized for automation. API key usage must then be closely watched by account administrators, as well as potential manual principal offboarding, if applies (also see for section "Manual offboarding"). Further security improvements for API key usage in LMC IdP user management scenarios are currently under research.
Identity Provisioning tool (IdP) based principal management was introduced to LMC to fulfill legal requirements done by the EU, and to make LMC principal management itself easier. To meet especially required access control criteria, the LMC as first step fully delegates identity proof to the IdP via OpenID Connect (OIDC) Auth code flow with Proof Key for Code Exchange (PKCE). The IdP verifies credentials (e-mail and password as stored in IdP), then issues a signed IDtoken that the LMC validates and uses to establish a local session for a specific principal identity. After verifying a principal's identity, LMC's inbuild session management gets applied.
Currently Microsoft EntraID with OIDC V2 endpoints, keycloak, Okta/ Auth0 and OpenTextAccess are proved to be working, and we expect any other IdP tool also to be working, whenever the OIDC standard is implemented correctly. In this scenario
login to LMC happens through the customer’s IdP.
LMC trusts only signed, validated responses and never sees or stores the principal’s primary credentials.
passwords, personal 2FA secrets and personal API keys of principals with a certain e-mail domain will be removed when enabling an IdP configuration for that domain, to raise security.
a non responsive IdP will lead to some typical HTTP errors. Only if the corresponding IdP configuration gets disabled by an account administrator, principals of the effected domain can use the "forgot password" function on LMC login screen to regain access. This will only work as long as the IdP configuration for that domain does not get re-enabled. Then again the LMC will remove passwords, second factors and principal bound API keys those principals may have set or created in the meantime.
To enable IdP principal authentication for principals of a certain domain, the corresponding IdP configuration can be done in any account of the LMC. Any change of the configuration will be shown in the account log of this account.
With IdP principal management and authentication enabled for a certain domain, principals of it will be able to create LMC accounts on their own by
Additionally LMC can be configured to evaluate which authority a certain principal will be granted, based on authorization data provided by the IdP and mappings done in LMC. The IdP then must supply identity and coarse-grained signals (groups/roles), which will result in a particular LMC principal role. Fine-grained checks are done with the LMC's own RBAC rules on every UI or API operation, using the established principal identity and account context. LMC memberships will not take effect for these principals, and no memberships for a principal will be stored to make sure a principal will always only be granted those rights which get retrieved from the current session's IDtoken information. It is not recommended to provide these principals additional direct memberships in the IdP authorized account (or account hierarchy), to not override rights granted by the IdP. Direct memberships for IdP authorized principals can be created at any time in any sibling account for granting access aside to the IdP authorized account (or account hierarchy).
As of January 2026
Whenever an IdP user account is disabled or the corresponding group membership/ app role changes in the IdP, the next LMC login or session validation with the IdP results in updated authorities or even access revocation in LMC.
Authentication and authorization in LMC is based upon signed JSON Web Tokens (JWTs). Using the signing mechanism other micro services can validate the integrity of any information sent in the token. Browser instances used by principals (clients) can request a dedicated endpoint to create new access tokens either based on username and password or existing tokens. Once issued the client can use this token (within the predefined time frame) to prove that she is both authenticated and authorized to access the requested part of the business logic. This is done by applying the token as part of each request in its header.
There are some consequences to the user experience, caused by the concept above:
IdP session handling follows the same principles as described above.
Logging in LMC happens at several places and log access is restricted to certain principal roles (organisation administrator at organisation level, project administrator and technical administrator at project level). Each log entry gets created together whilst processing the corresponding actions in the LMC backend. Log messages have different templates per type as well as for English and German language. Each service provides it's own translation templates for the corresponding message types. Log entries itself cannot be changed by any LMC principal, automation principal, nor service that created an entry. Database level log entry protection is not subject of this documentation.
Account audit logs on distribution, organisation and project level get stored for 365 days. Afterwards the corresponding database entries are deleted by automated database jobs. Only account administrators, or technical administrators of a project can access account audit logs. Typically actions done at the project settings or management pages get audit logged, e.g.:
Each account audit log entry contains at least an overview section, readable at first glance and without further interaction:
On explicit log entry expansion additional information gets displayed:
Audit log access with API keys is restricted to principal-bound keys of LMC managed account administrators and technical administrators of a project (also see for section "Alternative authentication methods").
Device logs can be accessed only on project level by project administrators, technical administrators and project members. To view a device log the particular device entity must be selected and the configuration pages entered. Each device log entry contains at least an overview section, readable at first glance and without any further interaction:
On explicit log entry expansion additional information gets displayed:
Device logs can be retrieved in an automated way by using either SIEM or principal-bound API keys (also see for section "Alternative authentication methods").
To make sure an LMC principal can no longer access resources that belong to a certain customer after an employee quit working for that particular company, there are mostly two ways to separate concerns in this case.
Principal offboarding for LMC managed principals requires manual steps to be performed by an account administrator (distribution, organisation and project, if applies). These actions must be done for each principal which should no longer have access to the LMC and include the following steps:
Offboarding for IdP managed principals require less manual work than offboarding LMC managed principals, but must performed with the same amount of attention.
For IdP authenticated principals the LMC stores direct memberships.
| Please pay close attention to the following: even if IdP principal authentication is enabled, always manually remove a principal's memberships to prevent password reset bypasses when an IdP gets disabled by an account administrator. |
For additionally IdP authorized principals also access rights are granted via returned values from the IdP. The LMC in this case does not store any memberships, so disabling or removing a principal or it's rights from the IdP responsible is sufficient to effectively block LMC access for a principal.
| Nevertheless, direct memberships of IdP authorized principals must be manually removed, too. Removing the LMC principal itself is optional, and must be done as described above. |
|