> ## Documentation Index > Fetch the complete documentation index at: https://docs.ankra.ai/llms.txt > Use this file to discover all available pages before exploring further. # Identity & Access Controls > The sign-in, MFA, role and token controls behind platform access - and the evidence each one produces for an audit. Access control is where most security questionnaires start and where most audit findings land. This page is the compliance view of Ankra's identity controls: what each control is, how to turn it on, and what evidence it produces. The step-by-step setup lives on the linked pages. *** ## Sign-in and SSO Ankra sign-in is handled by a managed identity provider rather than by password storage in the platform. Members authenticate there, and the platform receives the resulting identity. **Enterprise SSO**, which federates sign-in to your own identity provider so accounts follow your joiner-mover-leaver process, is available on the **Enterprise** plan. It is arranged with Ankra as part of onboarding rather than self-configured in the portal today. The phrase "SSO-backed" appears throughout these docs in a second, narrower sense: [Cluster Access](/guides/cluster-access) and [kubectl access](/guides/kubeconfig) mint short-lived Kubernetes credentials tied to the member's Ankra identity, rather than distributing static kubeconfigs. That is true on every plan and is a different control from enterprise SSO federation. Federating sign-in matters for two control families in particular: account provisioning and deprovisioning follows your directory, and your existing authentication policy - conditional access, device posture, session lifetime - applies to Ankra without Ankra needing to implement it. *** ## Multi-factor authentication Three second factors are supported, and an organisation can require MFA for every member. | Factor | Notes | | -------------------------- | -------------------------------------------------------------------------- | | Authenticator app (TOTP) | Six-digit codes from any authenticator app | | Passkeys and security keys | WebAuthn, covering platform passkeys and roaming keys - phishing-resistant | | Recovery codes | One-time use, issued at enrolment | When an organisation enforces MFA, a member who has not enrolled is blocked at sign-in until they do. That produces a clean binary answer to the "is MFA enforced for all users" question, and the state appears in the attestation section of the [compliance report](/security/compliance-management). Setup and CLI equivalents are in [Account Security & 2FA](/platform/account-security). If your framework distinguishes phishing-resistant MFA - and increasingly they do - steer members to passkeys rather than TOTP. Both satisfy a generic MFA requirement; only WebAuthn satisfies a phishing-resistant one. *** ## Roles and scopes Ankra grants permissions through **roles** assigned at a **scope**: the whole organisation, a single cluster, or a cluster group. A role can also bundle the Kubernetes access provisioned on every cluster the scope resolves to, so platform permissions and `kubectl` access are granted and revoked together rather than drifting apart. This is the structure that lets you answer least-privilege questions concretely: * **Scope narrowly.** An engineer who operates one team's clusters gets a role on that team's cluster group, not on the organisation. * **Separate duties with custom roles.** The audit read permission can be granted on its own, so a compliance function reviews and exports the trail without administrative access. The same applies to security read. * **Use dynamic cluster groups.** A group defined by a label selector keeps access correct as clusters are created and retired, instead of relying on someone remembering to update a static list. Roles, scopes and the CLI commands for managing them are documented in [Roles & Access](/guides/roles-and-access). *** ## Kubernetes access Cluster access is granted through Ankra rather than by distributing credentials. Members authenticate as themselves and receive short-lived tokens minted on demand, so there are no static kubeconfigs to leak, rotate or collect on offboarding. Requests reach the cluster through Ankra's authenticated proxy, which is why this works for private clusters with no inbound network path. See [Cluster Access](/guides/cluster-access) and [Accessing Clusters with kubectl](/guides/kubeconfig). Actions taken against the Kubernetes API - through Ankra's proxy or any other client - are recorded by your cluster's own Kubernetes audit policy, not by the Ankra audit log. If you need a trail of in-cluster API activity, enable Kubernetes audit logging on the cluster. *** ## API tokens Automation authenticates with API tokens rather than member credentials. For anything scheduled - evidence pulls, pipeline agents, integrations - issue a token for a member whose role grants only what the job needs, and treat the token as a credential with an owner and a review date. See [Tokens](/reference/tokens) for issuing and revoking them. *** ## Evidence map | Control | Where to get evidence | | ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | MFA enforced for all members | Attestation section of the [compliance report](/security/compliance-management) | | Who holds which role, at what scope | Role assignments under **Organisation** → **Settings**, and the [audit export](/security/audit-export) for changes | | Access changes over a period | [Audit export](/security/audit-export) filtered to access actions | | Joiner, mover, leaver activity | Invitation, assignment and revocation entries in the audit trail | | Privileged access review | Role assignments plus the agent's cluster-admin binding, covered in [Agent Compliance Posture](/security/agent-compliance) | | Credential handling | [Data Handling](/security/data-handling) for the secret lifecycle | An access review usually needs two things: the current state, and the changes since the last review. The assignment views give you the first and the audit export gives you the second. *** ## Related Define roles, scopes and cluster groups. Enrol factors and enforce MFA. Export access changes for review. Short-lived, identity-backed kubectl access.