An identity governance and administration (IGA) platform can create accounts and grant access in every system it connects to, so whoever controls the platform, its connectors or its source data controls access across the organisation. IGA is usually deployed to reduce access risk, and it is rarely assessed as a privileged system in its own right. This guide treats the IGA platform as a product class and covers how to secure it: administrative roles, connector and integration service accounts, keys and stored credentials, the integrity of the authoritative sources it trusts, custom workflow code, logging and the platform's own lifecycle. It is vendor-neutral and based on NCSC, NIST SP 800-53, OWASP and CIS Controls v8.1 guidance. It is written for IGA engineers, identity architects and security teams who assure identity infrastructure. For how IGA works, see IAM and IGA Basics.
Key takeaways
- Classify the IGA platform as tier 0 or tier 1. If its connectors can write to the directory or the identity provider, a compromise of the platform can create administrators; NCSC tiering guidance describes tier 0 as the root of trust that all other administration relies on, with administrators who can create highly privileged accounts as an example.
- Connector service accounts are the largest exposure. They often hold write or admin rights in every connected system; scope each one to what its operations need and protect its credential in a vault.
- Protect the inputs, not just the platform. A change to the HR feed or another authoritative source becomes a provisioning action; source integrity is part of platform security.
- Separate who configures, who approves and who audits. Platform administrators should not be able to approve their own access, edit certifications they are reviewed in, or delete audit history.
- Govern the governor. Put the IGA platform's own admin accounts, service accounts and API clients under the same certification and lifecycle rules it enforces elsewhere, with reviews performed outside the platform's admin team.
Why the IGA platform is a privileged system
The platform reads identity data from authoritative sources, computes who should have what, and writes accounts and entitlements into target systems through connectors. It also holds a complete map of who can access what, which is valuable reconnaissance. The table below sets out its attack surface.
| Component | What it can do | What an attacker gains |
|---|---|---|
| Admin console and admin roles | Change policies, roles, workflows, connectors and approvals | Grant any access, suppress reviews, alter audit settings |
| Connector and integration service accounts | Create, modify and disable accounts and groups in target systems | Direct write access to directories, cloud tenants, databases and applications |
| On-premises agents or gateways | Run connector operations inside the network | A foothold inside the network with stored target credentials |
| Authoritative source feeds | Trigger joiner, mover and leaver events | Create identities or change attributes that drive birthright access |
| Workflow, rule and script logic | Run custom code during provisioning and approval | Persistent logic that grants access or bypasses approval |
| API clients | Read identity data, submit requests, change configuration | Bulk data extraction or configuration change without the console |
| Identity and entitlement data | Hold the full access model | A map of privileged accounts and paths to target |
The ATT&CK techniques this enables include T1098 Account Manipulation and T1136 Create Account, carried out through a trusted provisioning channel that target systems will accept.
Administrative roles and access to the platform
- Dedicated admin accounts with phishing-resistant MFA: platform administrators use accounts that have no other role (CIS safeguard 5.4) and phishing-resistant MFA (CIS safeguard 6.5). NCSC advises separate accounts for privileged tasks and blocking web and email access from admin devices.
- Granular admin roles: split platform configuration, connector management, role and policy authoring, workflow development, help desk operations and audit reading. Full administration should be held by very few named people. NCSC: full, system-wide access should be the exception, not the norm.
- Separation of duties inside the platform: an administrator should not approve their own requests, certify their own access, or approve changes to the policies that govern them (NIST SP 800-53 AC-5). Model these as SoD rules in the platform itself; see the Segregation of Duties Guide.
- Just-in-time platform administration: keep standing full-admin membership to break-glass accounts and release admin roles through the PAM vault for a time window. See the Privileged Access Management Guide.
- Restrict where administration comes from: admin console and API access only from privileged access workstations or a management network, using IP or device conditions where the platform or the identity provider supports them.
- Supplier and integrator access: implementation partners and vendor support get named, time-boxed accounts with recorded sessions, removed at the end of each engagement.
Connector service accounts, agents and stored credentials
Each connector authenticates to a target with a service account or API client. Teams often grant full administration "to make the connector work", which turns every connected system into one hop from the IGA platform. The scoping below is our recommendation.
| Connector operation | Rights the account needs | Rights to avoid |
|---|---|---|
| Aggregation only (read) | Read accounts, groups and entitlements | Any write right |
| Joiner and leaver provisioning | Create, disable and update accounts in delegated containers or scopes | Domain-wide or tenant-wide administration |
| Group or role assignment | Modify membership of governed groups only | Modify membership of privileged groups unless they are governed through a separate, stricter workflow |
| Password reset | Reset passwords for in-scope users | Reset rights over administrators and service accounts |
- One account per connector and environment: never share a service account across targets or between test and production. Record each in the service account inventory (CIS safeguard 5.5); see the Service Account Security Guide.
- Vault and rotate connector credentials: where the platform can fetch credentials from a vault or secrets manager at run time, use that rather than storing them in connector configuration. Rotate on a schedule and after any administrator with access leaves (IA-5).
- Prefer certificate or federated authentication: for cloud and API targets, use certificate-based client credentials or workload federation where the target supports them, with short lifetimes, instead of long-lived client secrets.
- Harden agents and gateways: host them on dedicated, hardened servers in a management zone, limit outbound connections to target systems and the platform, and monitor them as tier 0 or tier 1 assets.
- Govern privileged groups separately: if the platform can add members to directory admin groups, require multi-party approval for those changes and alert on every one.
Keys, data protection and API clients
- Encryption keys: the platform encrypts stored credentials and sensitive attributes. Know where those keys live, who can access them and how they are rotated, following NIST SP 800-57 practice. Self-hosted deployments should keep keys outside the application database.
- Minimise sensitive attributes: import only the HR and identity attributes that policy needs. Fewer attributes reduce privacy exposure and the value of a data extract.
- API clients: one client per integration, scoped to the operations it needs and denied everything else by default (OWASP Authorization Cheat Sheet), owned by a named person, with credential expiry and inventory. Review API clients in every certification cycle.
- Non-production copies: test environments loaded with production identity data and connected to production targets are a common path around production controls. Mask data and point test connectors at test targets only.
Integrity of authoritative sources and custom logic
The platform trusts its sources. A record inserted into the HR feed can produce a new identity with birthright access, and an attribute change can move a user into a privileged role.
- Protect the source feed: authenticate the feed connection, restrict who can change HR records that drive access, and alert on unusual volumes of joiners or attribute changes. See the Identity Data Quality and Authoritative Sources Guide.
- Guard sensitive attribute changes: changes to attributes that map to privileged birthright roles (department, job code, cost centre) should route through approval rather than auto-provisioning.
- Treat rules and workflows as code: custom scripts and rules run with platform privileges. Keep them in version control, require peer review, test in non-production and deploy through change control (NIST SP 800-53 CM-3). Check for logic that skips approval for specific users.
- Configuration drift: export platform configuration regularly and compare it with the approved baseline (CM-6).
Logging and detection
NCSC advises logging and monitoring authentication and authorisation events and making every action traceable to a person or account. For the IGA platform, send these events to a SIEM that platform administrators cannot alter (AU-9):
| Event | Why it matters |
|---|---|
| Admin role assignment or change | New platform administrators are the fastest route to wide access |
| Connector configuration or credential change | Can redirect provisioning or expose target credentials |
| Workflow, rule or policy change | Can remove approvals or SoD checks |
| Direct provisioning outside a request | Access granted without the normal workflow |
| Changes to privileged group membership via connectors | Tier 0 change through a trusted channel |
| Certification reassignment, bulk approval or campaign cancellation | Reviews being bypassed |
| Bulk data export or API reads | Reconnaissance of the access model |
| Spikes in joiners or attribute changes from a source | Possible source tampering |
Correlate target-side events too: an account created in a directory by the connector account that has no matching request in the platform should raise an alert (AC-2(12), account monitoring for atypical usage).
Lifecycle of the platform itself
- Govern the platform's own identities: run a certification campaign for IGA admin roles, connector accounts and API clients, reviewed by someone outside the IGA admin team (AC-6(7)).
- Patching and upgrades: self-hosted platforms and agents need a patch cadence that matches their tier. For software-as-a-service platforms, the provider patches the service and the customer keeps agents, connectors and configuration current: a shared responsibility (SA-9).
- Backup and recovery: back up configuration and data, protect backups as sensitive, and test restore. Plan how provisioning is paused safely if the platform is compromised, so a recovered platform does not replay bad changes. See Recovering IAM and PAM After Ransomware or Domain Compromise.
- Decommissioning connectors: when a target is retired, disable the connector, remove its service account in the target and delete stored credentials.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | CIS Controls v8.1 |
|---|---|---|---|
| Platform admin accounts | AC-6(5) Privileged Accounts, IA-2(1) Multi-factor Authentication to Privileged Accounts | PR.AA-05, PR.AA-03 | 5.4, 6.5 |
| Separation of duties | AC-5 Separation of Duties | PR.AA-05 | 6.8 |
| Connector service accounts | AC-2 Account Management, IA-5 Authenticator Management | PR.AA-01 | 5.5 |
| Configuration and code change | CM-3 Configuration Change Control, CM-6 Configuration Settings | PR.PS-01 | 4.1 |
| Logging and monitoring | AU-9 Protection of Audit Information, AC-2(12) Account Monitoring for Atypical Usage | PR.PS-04, DE.CM-03 | 8.2 |
| Supplier responsibilities | SA-9 External System Services | GV.SC-07 | 15.4 |
Common failure patterns
- Domain or tenant admin for every connector: convenient during implementation and never reduced afterwards.
- Connector passwords that never change: stored in configuration years ago, known to former implementation partners.
- Admins who certify themselves: the platform's own admin roles are excluded from campaigns or reviewed by the same team.
- Unreviewed custom rules: scripts added during go-live run with full platform rights and nobody owns them.
- Test environments wired to production: a lower-assurance environment that can write to production targets.
- Accounts outside the platform's reach: access in systems that are not connected, such as external registries, SaaS tools and partner portals, is not deprovisioned by the platform and survives offboarding. Track disconnected applications with manual fulfilment tasks; see Orphaned and Dormant Accounts.
Practitioner checklist
- Assign the IGA platform a tier based on what its connectors can write, and protect it accordingly.
- Split admin roles and keep full administration to named break-glass and JIT holders.
- Scope each connector service account to its operations and vault its credential.
- Require multi-party approval and alerting for privileged group changes made through connectors.
- Put rules, workflows and configuration under version control and change review.
- Protect and monitor authoritative source feeds for tampering.
- Log platform admin, connector, policy and certification events to an independent SIEM.
- Certify the platform's own admins, connector accounts and API clients from outside the IGA team.
- Test backup, restore and a safe provisioning pause.
Standards and references
- NCSC: 10 Steps to Cyber Security, identity and access management
- NCSC: Secure system administration, risk manage administration using tiers
- NCSC: Secure system administration, use privileged access management
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- OWASP: Authorization Cheat Sheet
- CIS: Controls v8.1 Assessment Specification, Control 5 Account Management
- CIS: Controls v8.1 Assessment Specification, Control 6 Access Control Management
- CIS: Controls v8.1 Assessment Specification, Control 4 Secure Configuration of Enterprise Assets and Software
- CIS: Controls v8.1 Assessment Specification, Control 8 Audit Log Management
- CIS: Controls v8.1 Assessment Specification, Control 15 Service Provider Management
Related NHI Mgmt Group resources: Identity governance and administration (IGA) platform rollout playbook · Identity governance and administration (IGA) platform health check · Securing the identity provider (IdP) and SSO platform itself · Securing the privileged access management (PAM) vault itself · IGA Buyer's Guide