CloudPortal · Security & access

Decide who can do what in CloudPortal

Everyone gets a role and the permissions their work needs. Sign-in goes through your identity provider, and important events end up in the organization's audit log. Consultants, integrations and AI assistants only get what you give them, and their access ends on its own.

Book a walkthroughDocumentation
  • Six roles, plus per-member exceptions with Allow, Deny or Inherit
  • SSO with Microsoft Entra ID without an app registration, SCIM and required MFA
  • No one can hand out more permissions than they have themselves

The right permissions for every person

The role sets the baseline. From there you can fine-tune per person or group and choose which modules the organization uses.

  • Six roles

    Owner, Administrator, Operator, Member, Viewer and Support. Only an owner can appoint or remove an owner.

  • Per-member exceptions

    Choose Allow, Deny or Inherit for each permission in the modules. Members with custom permissions are marked in the member list, so they are easy to review.

  • Groups

    Put people who need the same module permissions in a group. Groups can also come from your identity provider through SCIM.

  • Modules for the whole organization

    Each module can be active, not enabled or hidden. A hidden module is not shown to anyone in the organization.

Your IT provider's access is visible

A role at your provider does not by itself give access to your organization. It takes a membership, a role assigned by the provider or a delegation from you. The member list shows who at the provider can reach the organization and what they can do.

Illustrative product view
Illustrative view: the roles in the organization and an excerpt from the audit log.

Sign-in through your identity provider

Your users sign in with their normal organization accounts. SSO decides how people sign in, not who gets in: anyone who signs in must already be a member of the organization.

  • Microsoft Entra ID in three steps

    Prove the domain with a TXT record, have an Entra administrator approve the connection and sign in once. You do not need to create an app registration or manage a client secret.

  • Other providers through OpenID Connect

    If you do not use Entra ID, you connect another provider, such as OneLogin, through OpenID Connect.

  • Require SSO and MFA

    Require everyone to sign in through your identity provider. With Require MFA, everyone who signs in with a password must use two-step verification, including your provider's staff.

  • Accounts through SCIM

    With SCIM, your identity provider creates and updates users, and groups are mapped to roles. When someone leaves a group, the permission can be removed automatically.

Illustrative product view
Illustrative view: SSO with Microsoft Entra ID, required SSO and MFA, and groups from SCIM mapped to roles.

Temporary access that ends on its own

Your provider's staff, consultants, integrations and AI assistants can get access without becoming regular members. The ground rule is the same for all of them: no one can hand out more than they have themselves, and access has an end date.

  • Your provider's staff

    Delegation

    Lend selected module permissions to a person at your IT provider, for example during a migration. The person does not become a member and sees neither your settings nor your member list.

    • Ends after 90 days at the latest
    • Sensitive permissions cannot be lent
    • Can be revoked immediately
    Read more: Delegation(documentation, opens on the documentation site)

  • Consultants

    External guest

    Give a consultant or partner outside your organization and your provider exactly the permissions the work requires.

    • Ends after 365 days at the latest
    • A responsible person and a purpose are required
    • No role and no groups
    Read more: External guest(documentation, opens on the documentation site)

  • Integrations

    API key

    A key belongs to the organization and only reaches the modules' API, never sign-in, members or settings. Sensitive permissions are never included.

    • Ends after 365 days at the latest
    • Shown only once, when it is created
    • Stops working if the person who created it no longer administers the organization
    Read more: API key(documentation, opens on the documentation site)

  • AI assistants

    AI connection through MCP

    The connection goes through the CloudPortal sign-in, and you choose the organization and permissions. Changes become proposals that an authorized person approves in the portal, unless the organization has chosen otherwise for ordinary changes.

    • Valid for 30 days, and ends after 14 days without use
    • Sensitive records and deletions always wait for a person
    • AI stays off until the organization turns it on
    Read more: AI connection through MCP

Traceable afterwards

When something has changed, you should be able to see who did it and when.

  • The organization's audit log

    Invitations, role changes and changed settings, with time, event and user. Filter by module, event type and date.

  • Changes in DNS

    Recent changes shows who changed what, when and with what outcome, with the value before and after. The actor can be a person, an API key or the system.

  • Calls from AI

    Every call from an AI assistant is logged, including calls that are denied, and appears in the organization's audit log.

The log shows events, identifiers and status, not the full content of what changed. It is meant for follow-up, not for backup or restore.

Frequently asked questions

Does SSO create accounts automatically?

No. SSO only decides how a person signs in. Anyone who signs in must already be a member of the organization, for example after an invitation. If you want accounts to be created automatically from your identity provider, use SCIM.

Can we require two-step verification?

Yes. With Require MFA, everyone who signs in with a password and reaches the organization must use two-step verification, including your IT provider's staff. Anyone who does not have it sets it up at their next sign-in. Signing in through SSO counts as meeting the requirement.

Can we get locked out if SSO stops working?

The Allow local login for owners setting keeps password sign-in as a fallback for owners, even when SSO is required. If you turn it off, you must confirm that there is another administrative way in.

What can our IT provider see in our organization?

Your provider's staff reach the organization through a role that the provider assigns, or through a delegation from you. A role at the provider does not by itself give access. The member list shows who at the provider can reach the organization and what they can do.

Can an AI assistant change DNS without anyone approving it?

Only if the organization has chosen that. By default every change becomes a proposal that an authorized person approves in the portal. An administrator can let ordinary changes be carried out directly, but sensitive records and all deletions always wait for a person.

How long does temporary access last?

A delegation to your provider's staff lasts at most 90 days and an external guest at most 365 days. An API key lasts at most 365 days and an AI connection 30 days. All of them can be ended earlier.

See how access works in practice

We show roles, SSO and the audit log in the portal, based on how your organization is set up.

Book a walkthrough Send a request by email