Secure Configuration Guide

About this guide

This guide explains how to access a Remedio SaaS tenant securely, how access is granted through device groups and roles, and how to remove administrative access. It gives the configuration Remedio recommends for each, and the security implications behind it.

It is published at https://trust.remedio.io/scg, with the markdown source at https://trust.remedio.io/scg.md and a machine-readable version at https://trust.remedio.io/scg.json. All three are produced from one file and available without a support request or login. When configuring a new tenant, work through the recommended secure configuration baseline as a checklist, then read the sections that follow for the detail behind each item. Questions go to your TAM or support@remedio.io.

Account model

Access is granted through roles you define. A role holds one or more permissions, and each permission pairs a device group with an access level.

Access is either Full or View. Full includes remediation. View is read-only.

Three consequences:

• The roles you created are the complete set of administrative objects. Audit those.
• Least privilege is controlled by the device group, not by the access level. A role that must remediate requires Full over every device in its group. Assign narrow device groups.
• A permission of Full over All my devices grants complete authority over the tenant, whatever the role is called.

A device group definition determines which devices every role using that group can reach. Widening a group widens each of those roles. Change group definitions under the same review as role changes.

Roles and users are managed at Settings > Permissions, on the Roles and Users tabs.

Securely accessing the tenant

Access path

Access is over HTTPS to the tenant FQDN. There is no other console entry point, and no administrative interface is exposed on any other port for SaaS tenants. Remedio provides the list of URLs requiring port 443 access to your primary technical contact at tenant creation.

Identity provider integration

Federate the tenant to your own identity provider over SAML rather than relying on local accounts. Authentication strength, MFA, and conditional access then come from systems you already operate and audit.

See the SaaS IdP (SAML) Integration Manual for the procedure.

Security implications:

• MFA is enforced by your IdP. Remedio provides no second factor of its own, so console access without federation has no MFA.
• Session lifetime, device compliance, and location conditions come from your conditional access policies and are yours to define and enforce. Remedio provides no equivalent controls of its own.
• Removing a user from your directory, or from the group mapped to their role, prevents further sign-in. It removes nothing inside Remedio. Their user record and any local account they hold both remain. See Decommissioning.
• Once SAML is integrated, local accounts can no longer be created in the UI. Request a break-glass account from your TAM or support@remedio.io if one is needed.

Changing the SAML configuration after integration changes who can log in. An incorrect configuration can lock out all federated users, or accept assertions from an unintended issuer. Change these settings only in a planned window, keep a tested break-glass local account available, and verify the certificate and entity ID against your IdP before saving.

Local accounts

Where SAML is not yet in place, local users are created either by your Customer Success Manager or at Settings > Permissions > Users > New, supplying email address, user name, optional title, and role.

The first account is issued by email at tenant creation with a temporary password, which must be changed at first login.

Treat local accounts as temporary, or as a documented break-glass exception:

• Keep the count as low as possible and record why each one exists.
• Never share a local account between people. Shared accounts remove attribution.
• Review them at least quarterly against joiner, mover, and leaver records.

Session behaviour

Sessions time out after one hour idle. The timeout is not customer-configurable.

Managing device groups

A device group is the unit a permission is granted over. Groups are managed at Settings > Device Groups. Built-in groups cover common scopes, such as Windows endpoints, macOS computers and Red Hat Linux, alongside the custom groups you create.

Creating a group

1. Go to Settings > Device Groups and click New.
2. Enter a name for the group, and a description if required.
3. Add devices using any of: the Device filter, to select named devices; criteria based on a built-in group, operating system, domain or OU; or a CSV import.
4. Click Save.

Static and dynamic membership

A group built from named devices or a CSV import holds a fixed list. A group built from criteria is evaluated continuously. Any device that later matches the criteria joins the group, and every role holding a permission over that group reaches that device without any change to the role.

The Label filter builds a group from a label you type. Labels are applied on the device, during sensor deployment or afterwards through the sensor CLI. Label changes appear in the console only after the device completes a full scan.

Managing administrative roles

Onboarding with your TAM creates one role holding Full on All my devices.

Creating

1. Open Settings > Permissions.
2. On the Roles tab, click New.
3. Enter a Role Name. Name the role by function rather than by the person holding it, so the name remains accurate when staff change.
4. Under Permissions, click Add. Choose a Device Group and an Access level, then click Add. Repeat for each group the role needs. Choose All my devices only where full-tenant authority is genuinely required, and Full only where the role must remediate.
5. Under Members, click Add and select users. Skip this step where access is granted through a directory group.
6. Click Create.

Recommended configuration:

• No more than two roles in the tenant holding Full on All my devices.
• At least two people assigned to the primary administrative role. A single holder risks lockout.
• Grant administrative access through a directory group rather than to named individuals. Create the role in Remedio, then have your IdP team create a group with an identical name and case, emitted in a claim named groups. Do not add members in the Remedio console.

Operating

• Do not use an administrative role for routine work. Assign day-to-day users a role limited to the device groups they work on, and reserve full-tenant authority for changes that need it.
• Review role membership, device groups and access level quarterly. Groups widened during an incident are frequently not narrowed afterwards.
• Record each role's purpose and owner outside Remedio, in your own access register. Roles created for a specific task outlive the task unless something tracks them.
• Check the membership of any directory group mapped to a role on the same cycle. Membership changes there take effect in Remedio at the next sign-in, without any change inside the tenant.

Decommissioning

When a person leaves the administrative function:

1. If federated, remove them from your directory or from the group mapped to their role. This prevents further sign-in but removes nothing inside Remedio. IdP-authenticated users are not listed as role members, so the Roles tab will not reflect the change.
2. If they held a local account, remove it at Settings > Permissions > Users. Directory removal does not touch local accounts.
3. If they were the only holder of a role, whether through a local account or through directory group membership, assign a replacement before removing them.

Recommended secure configuration baseline

Version history

Every change to a recommended default in the baseline table is recorded here, with the reason.