# IAM and Access

> Manage organisation access for members, groups, roles, service accounts, and API keys.

Identity and access management (IAM) controls who and what can use your organisation's Infuse resources.

Most organisation access management starts in the Infuse Portal under **Access management** in the sidebar:

- **Members** manages active members and invitations. Open a member to manage their baseline membership level, additional roles, direct grants, effective access, and personal API-key metadata.
- **Service accounts** manages non-human identities for shared integrations and unattended workloads. This section is shown only to administrators with principal-management access.
- **Groups** manages reusable collections of users and service accounts. Group members inherit every compatible role assigned to the group.
- **Roles** shows permissions, resource limits, assignments, and conditions. Administrators can create organisation roles or clone an Infuse-provided template.

Personal API keys are self-service credentials under the user menu > **API keys**. Service-account API keys are managed from the relevant service account under **Access management** > **Service accounts**.

Personal and service-account API keys are the standard credentials for both Infuse Platform APIs and the Infuse-IoT Cloud API. Legacy Infuse IoT admin keys are deprecated and being retired; see [API Keys](/docs/iam-and-access/api-tokens#legacy-infuse-iot-admin-keys).

## How Access Fits Together

<table>
<thead>
  <tr>
    <th>
      Concept
    </th>
    
    <th>
      What it represents
    </th>
    
    <th>
      Where to manage it
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      Member
    </td>
    
    <td>
      A person who belongs to the active organisation.
    </td>
    
    <td>
      <strong>
        Access management
      </strong>
      
       > <strong>
        Members
      </strong>
    </td>
  </tr>
  
  <tr>
    <td>
      Service account
    </td>
    
    <td>
      A non-human identity for an application, integration, agent, or unattended workload.
    </td>
    
    <td>
      <strong>
        Access management
      </strong>
      
       > <strong>
        Service accounts
      </strong>
    </td>
  </tr>
  
  <tr>
    <td>
      Principal
    </td>
    
    <td>
      An identity that can receive access. In an organisation, a principal is a user or service account.
    </td>
    
    <td>
      The relevant member or service-account page
    </td>
  </tr>
  
  <tr>
    <td>
      Group
    </td>
    
    <td>
      A reusable collection of users and service accounts. Members inherit every compatible role assigned to the group.
    </td>
    
    <td>
      <strong>
        Access management
      </strong>
      
       > <strong>
        Groups
      </strong>
    </td>
  </tr>
  
  <tr>
    <td>
      Role
    </td>
    
    <td>
      A named bundle of permissions, optional resource limits, conditions, and supported principal types.
    </td>
    
    <td>
      <strong>
        Access management
      </strong>
      
       > <strong>
        Roles
      </strong>
    </td>
  </tr>
  
  <tr>
    <td>
      Permission
    </td>
    
    <td>
      A single allowed action, such as viewing devices or managing IAM groups.
    </td>
    
    <td>
      Select a role under <strong>
        Access management
      </strong>
      
       > <strong>
        Roles
      </strong>
    </td>
  </tr>
  
  <tr>
    <td>
      API key
    </td>
    
    <td>
      A credential that authenticates its owning user or service account. It does not receive access separately.
    </td>
    
    <td>
      User menu > <strong>
        API keys
      </strong>
      
      , or a service account's <strong>
        API keys
      </strong>
      
       tab
    </td>
  </tr>
</tbody>
</table>

## Recommended Model

Use roles as the normal unit of access and grant the narrowest role that allows the work to succeed.

Use groups when several users or service accounts need the same access. Assign the role once to the group, then update membership as the team or integrations change.

Open a member or service account and use its **Access** view when you need to confirm what the identity can do now and why. The effective-access view separates additional direct roles, group-inherited roles, direct grants, and current effective permissions.

Use a personal API key for your own CLI or script when its actions should follow your current organisation access. Use a service account for a shared, production, or unattended workload whose identity and lifecycle must not depend on one person. Keep every key in server-side secret storage and rotate or revoke it when necessary.