Category: User Provisioning

Target System

Also known as: Target Resource, Managed System, Connected System

Simply put

In identity and access management, a target system is an application, database, directory, or other resource that an identity platform connects to in order to create and manage user accounts and their access. It is the system on the receiving end of provisioning and deprovisioning actions, rather than the identity platform itself. Note that the term also carries unrelated meanings in other fields such as engineering testing and firearms ranges, which are out of scope here.

Formal definition

A target system is the downstream application, directory, database, or infrastructure resource that an IGA or provisioning platform integrates with to manage the identity lifecycle, including account creation, attribute updates, entitlement grants, and deactivation. Integration is typically achieved through connectors implementing standards such as SCIM or through vendor-specific adapters, and the target system is the authoritative store for the accounts and entitlements being administered on it. It is primarily an IGA and provisioning concept concerned with lifecycle management, and should be distinguished from runtime enforcement points (PEP/PDP) that adjudicate access at request time; a single resource may play both roles depending on architecture. The evidence packet does not contain IAM-specific sources defining this term, so the definition above reflects standard practitioner usage rather than the cited materials.

Why it matters

The target system is where access ultimately lives. An identity platform can maintain flawless records of who should have what, but if the accounts, attributes, and entitlements are not accurately written to and revoked from the downstream applications, databases, and directories, that governance intent has no real-world effect. Orphaned accounts, stale entitlements, and failed deprovisioning almost always manifest at the target system, which is why it is the natural focus for access reviews, joiner-mover-leaver processes, and audit evidence.

Because the target system is the authoritative store for the accounts being administered on it, the fidelity of the connector between the identity platform and the target directly determines the reliability of governance controls. A deprovisioning action that succeeds in the identity platform but silently fails against a target leaves residual access that neither the platform's reports nor a casual audit will surface. This gap between intended state and actual state on target systems is a recurring theme in access-related findings during certification cycles and regulatory audits.

It is also worth noting that the term "target system" carries entirely unrelated meanings in other domains, such as the entity under test in engineering robustness testing or the physical apparatus on a firearms range. Those usages are out of scope for IAM, and practitioners should not confuse the identity-lifecycle sense described here with them.

Who it's relevant to

IGA and provisioning engineers

These practitioners build and maintain the connectors that link the identity platform to each target system. They are responsible for mapping attributes, configuring SCIM or vendor-specific adapters, and ensuring that provisioning and deprovisioning actions reliably reach the downstream resource and reconcile correctly against its authoritative state.

Identity governance leads

Access reviews, certifications, and segregation-of-duties analysis all depend on accurate visibility into the entitlements that actually exist on target systems. Governance leads care whether the platform's recorded state matches the real state on each connected system, since discrepancies undermine the validity of certification decisions.

Compliance officers and auditors

Audit evidence for joiner-mover-leaver controls and timely deprovisioning is drawn from the state of accounts on target systems. These stakeholders need assurance that revocation actions succeed at the target and that residual or orphaned access can be detected, since failures typically surface as findings tied to specific connected systems.

System administrators of managed resources

Administrators of the applications, directories, and databases being managed must expose the interfaces the identity platform integrates with and account for accounts created or modified directly on the system outside the governance flow, which reconciliation is designed to catch.

Inside Target System

Provisioning Target

In IGA contexts, a target system is a downstream application, directory, or platform to which identities and their entitlements are provisioned, updated, and deprovisioned. Provisioning is a lifecycle-management function and is distinct from runtime access enforcement.

Connector or Integration Layer

The mechanism through which an identity platform communicates with the target system. Depending on the deployment, this may be a standards-based interface such as SCIM for provisioning, an LDAP interface for directory targets, or a vendor-specific or agent-based connector.

Account and Entitlement Model

The representation within the target system of accounts, group memberships, roles, or other entitlements that a governance system manages. The access-control model exposed varies by target, some expose RBAC-style roles or groups, others expose finer-grained attributes or permissions, so the governance mapping depends on the target's own model.

Authoritative vs. Managed Relationship

A target system is typically a managed (downstream) system that receives identity data, as distinct from an authoritative source (such as an HR system) that originates identity data. A single system can occupy different roles in different flows depending on configuration.

Reconciliation and Certification Data

Data read back from the target system to support access reviews, certification campaigns, and segregation-of-duties analysis. This supports IGA governance functions rather than real-time policy decisions made by a PDP/PEP at runtime.

Common questions

Answers to the questions practitioners most commonly ask about Target System.

Is a target system the same as an identity provider?

No. A target system is a downstream application, directory, database, or platform that receives identity data and access changes from an IGA or provisioning system. An identity provider, by contrast, is typically the authoritative source that authenticates principals and asserts identity to relying parties. A target system is generally on the receiving end of provisioning and may consume, rather than assert, identity information, though in some deployments a single system can play both roles depending on architecture.

Does provisioning a user to a target system grant that user access at runtime?

Not by itself. Provisioning to a target system is an identity governance and administration (IGA) lifecycle activity that creates, updates, or removes accounts and entitlements. Whether a provisioned account can actually authenticate and what it may do at runtime depends on separate authentication and authorization enforcement within the target system. Provisioning establishes the account and its assigned entitlements; runtime access decisions are made when the principal attempts to use the system, and the two concerns should not be conflated.

How are entitlements typically pushed to a target system?

The mechanism depends on what the target system supports. Where available, SCIM is commonly used for standardized provisioning of accounts and, depending on the profile and configuration, group or entitlement data. Other integrations rely on directory protocols such as LDAP, vendor-specific APIs, database connectors, or agent-based approaches. The chosen method affects which attributes and entitlements can be synchronized and whether changes are pushed in real time or on a scheduled basis, depending on the connector and deployment.

How should deprovisioning to a target system be handled to avoid orphaned or lingering access?

Deprovisioning behavior varies by target system and connector. In most deployments, options include disabling versus deleting accounts, revoking specific entitlements, and reconciling accounts that exist in the target but not in the authoritative source. To reduce lingering access, teams typically define whether removal is immediate or scheduled, confirm that the connector supports the required action, and run reconciliation to detect orphaned accounts. Note that account removal in a target system does not necessarily invalidate already-issued tokens or active sessions, which are governed by separate enforcement and session controls.

What should be done when a target system does not support SCIM or a standard provisioning protocol?

When a target system lacks SCIM or another standard interface, integration typically relies on alternatives such as vendor-specific APIs, LDAP where applicable, database or file-based connectors, or agent-based mechanisms. The trade-offs generally involve which attributes and entitlements can be synchronized, whether changes propagate in real time or in batch, and the maintenance burden of custom connectors. Capabilities are constrained by what the specific target exposes, so the exact scope depends on the system and connector rather than a universal capability set.

How does access certification relate to entitlements held within a target system?

Access certification is an IGA process in which reviewers periodically confirm that principals should retain the entitlements they hold, including those provisioned into target systems. For certification to be meaningful, the entitlement data collected from each target system generally needs to be accurate and current, which often depends on reconciliation between the governance platform and the target. Certification decisions may trigger downstream deprovisioning actions, but the certification review itself is a lifecycle activity distinct from the runtime enforcement that governs whether access is actually permitted within the target system.

Common misconceptions

A target system enforces access decisions on behalf of the identity platform in real time.

Provisioning to a target system is a lifecycle-administration activity that creates or updates accounts and entitlements; it is separate from runtime enforcement performed by components such as a PEP and PDP. In most deployments the target system enforces access using whatever entitlements it currently holds, independent of the provisioning event that set them.

Any target system can be integrated the same way because SCIM is universal.

Integration methods vary by target. Some systems support SCIM for provisioning, others expose LDAP, and many require vendor-specific or agent-based connectors. The available interface and the target's own entitlement model determine what can be managed and how, so behavior depends on the specific target and configuration.

A target system and an authoritative source are interchangeable roles.

A target system is typically a downstream recipient of identity data, whereas an authoritative source originates it. A given system may act as a target in one flow and as a source in another, but conflating the two roles obscures where identity data is mastered versus consumed.

Best practices

Document each target system's integration method (SCIM, LDAP, or vendor/agent-based connector) and the entitlement model it exposes, since these determine what can be provisioned and reconciled.

Clearly designate whether a system acts as an authoritative source or a managed target in each flow, and avoid mixing the two roles without explicit configuration.

Keep provisioning and deprovisioning lifecycle events distinct from runtime enforcement expectations; verify that deprovisioning to a target actually revokes the underlying entitlements the target enforces.

Schedule regular reconciliation between the identity platform and each target to detect drift, orphaned accounts, and out-of-band changes that bypass provisioning.

Feed target-system entitlement data into access reviews, certification campaigns, and segregation-of-duties analysis to support governance rather than assuming provisioning alone ensures appropriate access.

Validate connector behavior against each target's specific capabilities and limitations rather than assuming standardized behavior across all targets.