A Genesys Cloud organisation holds call recordings, transcripts, customer contact data and the routing logic that decides who answers every interaction, so the identities that administer it and the integrations that call its API deserve the same care as any core business system. This guide covers the customer-side controls Genesys provides: roles and divisions, SSO and multi-factor authentication, allowed IP addresses, OAuth clients for integrations and SCIM, recording encryption with Genesys managed keys, a Local Key Manager or AWS KMS, and the Audit Viewer with its API and Amazon EventBridge options. It is written for Genesys Cloud administrators, contact centre platform owners and the security teams that support them. For fraud and voice channel risks such as synthetic voices and social engineering of agents, see the Voice AI Agent Security and Fraud Guide; this page stays with platform configuration.
This is an independent guide from NHI Mgmt Group, based on Genesys's public documentation as of November 2026. It is not sponsored or reviewed by Genesys. Product features change, so confirm settings against Genesys's current documentation.
Key takeaways
- Roles plus divisions define reach. A role says what a user can do; the divisions attached to that role say which queues, flows, users and recordings it applies to. Plan both together.
- Turn on SSO only, or MFA for local logins. "Disable Genesys Cloud Login" forces every user through your identity provider; where local logins remain, "Require Multi-Factor Authentication" applies MFA organisation wide.
- Treat OAuth clients as service accounts. Client credentials grants carry roles and divisions, the secret is shown once, and token lifetime is configurable from 300 seconds to two days.
- Choose who holds the recording keys. Recordings use envelope encryption; you can keep Genesys managed keys, run a Local Key Manager, or wrap keys with your own AWS KMS key.
- Export audit events early. The Audit Viewer shows the last 14 days, so collect older history through the Audit APIs or Amazon EventBridge into your SIEM.
How identity and access work in Genesys Cloud
Every user receives the Employee role when added, and Genesys documents that it cannot be removed. Additional capability comes from extra roles, and because roles also assign licences, role design affects both access and cost. The person who creates the organisation receives the Admin role and invites others.
Divisions
Divisions are the primary units for segmenting access. Every organisation has a single Home division that cannot be deleted, though it can be renamed. A role can be granted for one division, several or all of them, and each configuration object belongs to exactly one division. Division-aware objects include queues, users, flows, schedules and scripts, plus outbound campaigns, contact lists and Do Not Contact lists. Transactional data such as conversations, recordings and audit data is associated with divisions automatically as it moves through the system.
Two details matter for least privilege. First, some resources are not assigned to any division (Genesys lists examples such as wrap-up codes, external contacts and external organisations) and are visible to anyone with the right permission, whatever their divisions. Second, when your organisation is paired with an authorised organisation such as a partner or managed service provider, its users can reach every division tied to the roles you grant them, so review those grants as carefully as your own staff.
Authentication options
| Control | Where (Genesys docs) | What it does | Recommended use (NHI Mgmt Group recommendation) |
|---|---|---|---|
| Single sign-on providers | SSO integrations (Genesys SSO articles) | Connects one or more identity providers through a single interface | Use your workforce identity provider with its own MFA and conditional access |
| Disable Genesys Cloud Login | Menu > Account > Organization Settings > Authentication | Users must sign in through SSO; password requirement options are disabled; you cannot delete all SSO providers while it is on | Turn on once SSO is tested for all user groups |
| Require Multi-Factor Authentication | Same tab, under Genesys Cloud Login | All users set up MFA (device code or passkey) from first login | Turn on wherever Genesys Cloud login stays enabled |
| Allowed IP addresses | Organization Settings > Settings tab | Up to 150 IPv4 CIDR blocks; limits users, groups and API applications; an empty list allows all addresses | Use where agents and integrations work from stable egress addresses |
Before turning on SSO only, check one documented exception: Genesys notes that webhooks used for chat notification integrations need password-based authentication and stop working when SSO only is active. Before requiring MFA, make sure administrators know how to reset a user's MFA device, because agents who lose a phone otherwise cannot take calls.
The IP allowlist is checked against the configuring user's own address, and Genesys warns against enabling it with dynamic IP addresses. If you also use attribute-based access control (ABAC) policies with IP conditions, the allowlist is evaluated first and the ABAC ranges must sit inside it; Genesys recommends using one method rather than both. For the identity provider side of this design, see the Identity Provider and SSO Security Guide.
Admin roles and privileged access
Genesys ships default roles and lets you build custom ones. The default roles most relevant to security are listed below.
| Role | Scope (Genesys docs) | Least-privilege guidance (ours) |
|---|---|---|
| Admin | Full control over organisation changes | Two or three named people, SSO with phishing-resistant MFA at the identity provider, reviewed quarterly |
| Telephony Admin | Edge devices, phones, numbers and call routing | Telephony engineers only; routing changes can redirect customer calls |
| Quality Evaluator | Evaluation forms, audit trails, recording annotation; can create recording encryption keys | Separate key management from evaluation with a custom role where possible |
| Supervisor | Default role (formerly PureCloud Supervisor); permissions listed in Genesys's products, roles and permissions list | Review its permission set before use and grant only for the divisions the supervisor manages |
| People Admin | People management (organisations created after 1 June 2022) | Service desk or HR operations |
| Employee | Read organisation data, edit own profile | Baseline for everyone; cannot be removed |
Custom roles
- Build from tasks, not titles: create custom roles that contain only the permissions a job needs, then grant them per division.
- Avoid wildcard permissions: Genesys advises against wildcards in custom roles, partly because new billable permissions can be added to them automatically.
- Watch default role updates: Genesys adds new permissions to default roles over time. Restoring a default role adds back new and deleted permissions but removes custom permissions you added, so record your changes before you restore.
- Allow for propagation: permission changes can take a few minutes to apply, so test after a short wait.
Sensitive permissions to track include SSO provider permissions (Single Sign-on > Provider), the Directory > Organization admin permission, recording encryption key permissions (Recording > Encryption key View and Edit), audit viewing, and OAuth client management. Keep a list of who holds each, and review it each quarter (our recommended cadence). See the SaaS Admin Account Protection guide.
Integrations, API tokens and service accounts
OAuth clients are created under Menu > IT and Integrations > OAuth > Add client. Each client is a non-human identity with its own grant type, roles, divisions and token lifetime.
| Grant type | Use (Genesys docs) | Guidance |
|---|---|---|
| Client Credentials | Non-user applications such as a service or scheduled job; cannot call user-specific APIs such as GET /v2/users/me | Give minimum roles, set divisions explicitly, store the secret in a secrets manager |
| Code Authorization / PKCE | Two-step flow exchanging a code for a token; described by Genesys as the most secure option | Default for user-facing and server-side apps |
| Token Implicit Grant (Browser) | Single-step browser flow; creation of new implicit clients is blocked after 25 May 2026, existing clients keep working | Plan migration of existing clients to Code Authorization with PKCE |
| SAML2 Bearer | Exchanges a SAML2 assertion for a bearer token, typically with SSO | Use only where the integration needs it |
Client credentials hygiene
- Roles you hold: you can only grant a client roles that are in your own profile, which keeps delegation bounded. Assign the minimum set.
- Divisions: roles on a client default to the Home division. Set the divisions the integration really needs, and confirm division settings with any third party that supplies the integration.
- Token duration: the standard range is 300 to 172,800 seconds. Shorter is safer; our view is one hour or less for back-end jobs unless the integration documents a need for more. Genesys suggests 64,800 seconds for the Embeddable Framework, and HIPAA-enabled organisations also get a 15-minute idle timeout on tokens.
- Secrets: the client secret is shown once at creation. Store it in a secrets manager, and use "generate a new secret" to rotate. Rotate at least yearly and on any staff or supplier change (our recommendation).
- Ownership: record an owner, purpose and review date for every client, and delete clients that no audit event shows in use.
SCIM provisioning
SCIM uses an OAuth client too. Its token defaults to 86,400 seconds and can run to 38,880,000 seconds (450 days) when the client holds only the SCIM Integration role or equivalent permissions; adding other roles returns the duration to the default. That long lifetime makes the SCIM token a privileged credential: keep the client limited to the SCIM role, store the secret in a vault and put a reminder on the expiry date. See the SCIM Provisioning Guide and the SaaS and OAuth App Governance Guide.
Recording encryption and key ownership
Genesys encrypts call recordings, digital recordings (email, chat and message) and transcripts with envelope encryption: a unique AES 256-bit data encryption key per recording, protected by RSA 3072-bit key encryption key pairs. Screen recordings use Amazon S3 server-side encryption with SSE-S3 keys. Keys are managed under Menu > Conversation Intelligence > Recording and Policies > Encryption Keys (or Admin > Quality > Encryption Keys).
| Key configuration | Who holds the keys | Choose it when | Operational note |
|---|---|---|---|
| Genesys Cloud Managed Keys | Genesys generates, stores and owns the key pairs | You want the lowest operational load | Rotate key encryption keys in the Encryption Keys page on a schedule |
| Local Key Manager | Your organisation generates and stores the key pairs | Policy requires keys held on your own infrastructure | Genesys states it has no way to recover recordings if these keys are lost, so back them up |
| AWS KMS Symmetric | Your AWS KMS key wraps the private keys; Genesys can decrypt only while you grant access | You want customer control and revocation using AWS KMS | Key must be in the same core region as your Genesys home region |
Setting up AWS KMS
- Create a customer managed symmetric key in the matching AWS region and give it an alias.
- Write the key policy to allow the Genesys Cloud AWS account published in the Genesys article to use
kms:Encrypt,kms:Decrypt,kms:GenerateDataKey*andkms:DescribeKey. - Add a condition on
kms:EncryptionContext:genesys-cloud-organization-idso only your organisation IDs can use the key. - In Genesys Cloud, set Key Configuration Type to AWS KMS Symmetric, enter the alias ARN, choose a Periodic Key Change interval, click Test, then save. The configuring user needs Recording > Encryption key View and Edit.
- For rotation, either let AWS rotate automatically and match the Periodic Key Change cadence, or create a new key with the same policy, repoint the alias and click Change Key Now.
Keep old key material for at least your recording retention period, because historical recordings need it. If Genesys cannot reach KMS, new recordings are encrypted with the last known public key, but nothing can be decrypted until access returns, so treat changes to the key policy as a change-controlled event. See the AWS KMS Security Guide and the BYOK, HYOK and External Key Management Guide.
Logging and detection
The Audit Viewer records administrative and service events. A full-page viewer sits on the Admin page and a mini viewer appears in the footer of administrative pages. Viewing needs the Admin role and the Audits > Audit > View permission. You can filter by service, entity type, action, entity ID and user name, and open a detailed view of each event.
The viewer shows only the last 14 days, and each search window is limited to 14 days. Older events are reachable through the Audit APIs, and Genesys points to the Amazon EventBridge integration for bulk delivery of audit events as JSON into AWS, where you can route them to a SIEM or long-term storage. Set up collection before you need it. See the SaaS Audit Log Retention and Licensing Guide.
| Event area | What to alert on | Why |
|---|---|---|
| Authentication settings | SSO provider changes, Disable Genesys Cloud Login cleared, MFA requirement cleared, IP allowlist edited | Changes the front door for every user |
| Roles and divisions | Admin role granted, roles granted for all divisions, new custom roles with wide permissions | Privilege growth outside change records |
| OAuth clients | Client created, secret regenerated, roles added to a client | New or changed non-human identities |
| Recording and keys | Encryption key configuration changed, recording policy changed | Affects confidentiality and retention of recordings |
| Telephony and routing | Number, trunk or flow changes | Routing changes can redirect or expose customer calls |
Metrics that show it is working:
- Share of users signing in through SSO (target 100% once SSO only is on).
- Number of users holding Admin, and roles granted for all divisions (trend down).
- OAuth clients with a named owner and a secret rotated in the last 12 months.
- Days of audit history held outside Genesys Cloud (target at least your retention policy).
- Days since the last recording key change, compared with your rotation interval.
Hardening baseline
A phased rollout. Most settings revert by clearing the same checkbox, so pilot each change and keep a rollback note.
- Inventory: export users by role and division, list OAuth clients with grant types and roles, list authorised organisations.
- Start audit collection: connect the Audit APIs or EventBridge integration so the baseline itself is logged.
- Configure SSO: add the identity provider, test with a pilot group across agents, supervisors and admins.
- Enforce sign-in: turn on Disable Genesys Cloud Login after checking chat notification webhooks; if local logins must stay, turn on Require Multi-Factor Authentication.
- Restructure divisions: group queues, flows and users by business unit or region, and move objects out of the Home division.
- Right-size roles: replace broad grants with custom roles per division; cut Admin holders to named people.
- Clean up OAuth clients: set divisions, shorten token durations, rotate secrets into a vault, retire unused clients, and plan the move off implicit grants.
- Choose recording key management: confirm Managed Keys, Local Key Manager or AWS KMS, and set a periodic key change.
- Add network limits: where egress addresses are stable, add the IP allowlist, including your own address first.
- Schedule reviews: quarterly role and OAuth reviews, yearly key and secret rotation checks (our recommendations).
| Organisation profile | Priority choices |
|---|---|
| Single-site contact centre | SSO only, few Admins, OAuth client ownership, Audit API export, Managed Keys with scheduled rotation |
| Multi-region or outsourced operation | Divisions per region or provider, careful authorised organisation grants, IP allowlist per site, SIEM integration |
| Regulated (health, finance) | All of the above plus AWS KMS or Local Key Manager, HIPAA token timeouts where applicable, documented key procedures |
Common misconfigurations
- Everything in the Home division: roles then reach every object. Create divisions early and assign objects when you create them.
- OAuth clients with default divisions and long tokens: set divisions explicitly and keep token duration short.
- SSO enabled but local login left on without MFA: either turn on Disable Genesys Cloud Login or Require Multi-Factor Authentication.
- Restoring a default role without notes: custom permissions disappear. Record changes first.
- Customer keys without a recovery plan: back up Local Key Manager keys and keep old KMS key material for the full retention period.
- Relying on the 14-day viewer: collect audit events into a SIEM before an investigation needs them.
Follow Genesys release notes and apply recommended changes to integrations promptly.
Framework mapping
| Genesys Cloud control | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ATT&CK technique it helps address |
|---|---|---|---|
| SSO only, MFA, IP allowlist | IA-2, AC-17 | PR.AA-03 | T1078.004 Cloud Accounts |
| Roles, divisions, authorised organisation review | AC-2, AC-6 | PR.AA-05 | T1098 Account Manipulation |
| OAuth client roles, token duration, secret rotation | IA-5, AC-6 | PR.AA-01 | T1528 Steal Application Access Token |
| Recording encryption and key management | SC-12, SC-28 | PR.DS-01 | T1530 Data from Cloud Storage |
| Audit Viewer, Audit APIs, EventBridge | AU-6 | DE.CM-03, PR.PS-04 | T1098 Account Manipulation |
Practitioner checklist
- SSO configured and tested; Disable Genesys Cloud Login on, or Require Multi-Factor Authentication on for local logins.
- Admin role limited to named people; custom roles without wildcard permissions.
- Divisions in place, objects moved out of the Home division, and no unexplained all-division grants.
- Authorised organisation grants reviewed against contract scope.
- Every OAuth client has an owner, explicit divisions, a short token duration and a vaulted secret.
- Implicit grant clients listed with a migration plan to Code Authorization with PKCE.
- SCIM client limited to the SCIM Integration role with a tracked token expiry.
- Recording key configuration chosen and documented, with periodic key change set.
- Audit events exported through the Audit APIs or EventBridge with alerts on the events above.
- IP allowlist in use where egress addresses are stable.
Standards and references
- Genesys: About roles and permissions
- Genesys: Divisions overview
- Genesys: Create an OAuth client
- Genesys: Configure Genesys Cloud to authenticate with SSO only
- Genesys: Enable multi-factor authentication
- Genesys: Recording encryption key overview
- Genesys: Use an AWS KMS symmetric key for recordings
- Genesys: View audit events
Related NHI Mgmt Group resources: Voice AI Agent Security and Fraud Guide, Caller Authentication in Contact Centres, SaaS Security Guide, Secrets Management Guide.