The team is the top-level organizational concept in ScaleFT. A team fundamentally consists of a unique name and an associated Identity Provider.

All other configuration objects in ScaleFT are scoped to a team.

Team documentation

Identity Provider (IdP)

Every team has an Identity Provider (such as Google, Okta, Active Directory, or LDAP) which users authenticate to using the team’s authentication method (such as OAuth). The IdP is the source of truth for that user’s identity and current access. Different Identity Providers support different authentication methods (such as OAuth or SAML).

Authentication Method documentation


A user is a person who belongs to a team and authenticates with that team’s identity provider. The permissions of a user in ScaleFT are determined by their group memberships.

Users authorize clients to be added to their client inventory so they can receive credentials.

Server User Accounts

User accounts on Linux and Windows servers can be managed by the ScaleFT Agent.

Server User Account Management documentation

Service User

A service user is an abstraction for services or software automation which can be granted specific authorizations in ScaleFT. Like users, service users belong to teams, and their permissions are determined by their group memberships. Service users can be used for automating actions against the ScaleFT API, or be granted credentials to servers.

Service User documentation


The ScaleFT client is installed on a device (such as a laptop or workstation) which a user uses to access infrastructure. The ScaleFT client manages the dynamic credentials on the device so the user can transparently access ScaleFT-managed resources.

Client Enrollment documentation


Groups are used to grant permissions (such as administrative configuration rights) to users within the ScaleFT dashboard and API, and can be linked to projects to grant permissions within that project.

Group documentation


The project is the organizational concept in ScaleFT which connects resources (such as servers or internal services) with RBAC configurations. You can think of it like a Domain in Active Directory or a Realm in Kerberos.

Project documentation

Dynamic Credentials

You can also think of projects as programmable Certificate Authorities which issue ephemeral certificates in accordance with your RBAC configurations.

Each of these certificates contains at least the following information:

  1. The ScaleFT project for which the certificate was issued
  2. The username to be used on the server of the ScaleFT user to whom the certificate was issued
  3. The time at which the certificate expires

Since ScaleFT credentials are short-lived, and scoped to a project, even if a credential is compromised by an attacker, the attacker has a very limited window of time to use the certificate before it expires, and it is only of use against resources in that project.