Informatica IDMC Security: Harden Secure Agents, Connection Credentials, Roles and SAML

Informatica Intelligent Data Management Cloud (IDMC) runs data integration jobs on Secure Agents inside your network, using connection credentials that reach your most sensitive systems, so the agent hosts, those credentials and the roles that can change them are where most of the security work sits. This guide covers the customer side of IDMC security: Secure Agent installation and host hardening, where connection credentials are stored and how to move them to an external secrets manager, system defined roles, SAML single sign-on with role mapping, organisation authentication settings, the security log, and security points to plan for during a PowerCenter modernisation. It is written for IDMC organisation administrators, platform engineers and security teams. For controls common to every pipeline tool, see the ETL and ELT Pipeline Security Guide.

This is an independent guide from NHI Mgmt Group, based on Informatica's public documentation as of November 2026. It is not sponsored or reviewed by Informatica. Product features change, so confirm settings against Informatica's current documentation.

Key takeaways

• Secure Agents are privileged hosts. They connect out on port 443 to your IDMC POD, run jobs with your connection credentials and, on Windows, sit in the local Administrators group; harden and monitor them like any server holding production secrets.
• Decide where credentials live. Connection properties are stored either in the IDMC repository (Informatica Cloud) or on one Local Secure Agent; only the cloud option can pair with AWS Secrets Manager, Azure Key Vault or HashiCorp Vault.
• Use a secrets manager for sensitive properties. With Enable Secret Vault and Use Secret Vault, a local Secure Agent fetches passwords, OAuth tokens and shared secrets at run time, so they are not held in IDMC.
• Map SAML groups to roles. Turn on Map SAML Groups and Roles so IDMC roles follow your identity provider, and keep Admin and Key Admin to a small named group.
• Tighten organisation authentication. Enable multi-factor authentication for native users, trusted IP ranges, a strong password policy and JWT authentication, and review the security log, which keeps 400 days of events.

How identity and access work in IDMC

IDMC splits into a cloud control plane, where users design assets, schedule jobs and administer the organisation, and runtime environments, where Secure Agents move the data. Users authenticate to the control plane natively or through SAML. Secure Agents authenticate to the control plane with credentials issued at registration and to your systems with connection credentials. Each layer has its own controls.

Organisation authentication properties

Set these under the organisation's authentication properties in Administrator:

• Minimum Password Length and Minimum Character Mix: length can be set from 4 to 12 characters; choose 12 and require several character types for native users.
• Password Reuse and Password Expires: block reuse; set expiry in line with your password policy.
• Enable Multi-Factor Authentication: sends native human users an email verification code at sign-in, so every native user needs a valid email address.
• Session Idle Timeout: defaults to 30 minutes, with a warning 60 seconds before logout.
• Authentication Type: defaults to Session ID; JSON Web Token (JWT) is the alternative, with a token expiry that defaults to 30 minutes.
• Use Trusted IP Ranges and Allowed Trusted IP Ranges: restrict sign-in to your corporate egress and VPN ranges, IPv4 or IPv6.

SAML single sign-on

SAML setup exchanges metadata: you enter the identity provider settings and attribute mapping in IDMC, then give the identity provider the Informatica service provider metadata and single sign-on URL. Choose between authentication only and authentication with authorisation:

• Authentication only: IDMC checks credentials at each sign-on but roles are assigned in Administrator.
• Map SAML Groups and Roles: IDMC reads groups and roles from the token and assigns the IDMC roles mapped on the SAML Role Mapping and SAML Group Mapping tabs. Unmapped groups are ignored. Changes take effect at the user's next SAML sign-on, which can change the privileges of scheduled jobs, so test mapping changes before rollout.
• Auto-provisioning: creates users at first sign-on and fails the login if the token carries no roles or groups. With Enable IdP to push users/groups using SCIM 2.0, the identity provider (Okta or Microsoft Entra ID, which the docs call Azure Active Directory) creates and deactivates users instead. Keep SAML group mappings aligned with SCIM changes, because a SAML sign-on overrides SCIM group membership.

SAML users have read-only profiles and no IDMC password, which keeps credential policy in your identity provider. Native users keep repository stored passwords, so limit them to break glass and service integrations. See the SAML Security Guide.

Admin roles and privileged access

IDMC ships system defined roles that span services. The ones that carry the most privilege:

• Separate production: use separate organisations or sub-organisations for development and production, and keep Designer out of production for most users so connection changes go through deployment.
• Guard the secrets manager settings: configuring the secrets manager needs Admin, or both the SMS Manage Connection and SMS View Connection feature privileges plus Administrator access. Treat those privileges as admin.
• Limit log access: viewing the security and asset logs needs the Audit Log - View privilege; give it to the security team and auditors.
• Use custom roles for narrow jobs: where a system defined role is broader than the task, build a custom role with only the needed privileges. See the Least Privilege Techniques Guide.

Integrations, API tokens and service accounts

Secure Agent hosts

Secure Agents are installed from Administrator, Runtime Environments, Download Runtime Installer, with an install token that expires after 24 hours. Harden the hosts:

• Linux: install as a dedicated user, never root, with full access to the installation directory only. One agent runs per user account.
• Windows: the agent needs the local Administrators group. Run the Informatica Cloud Secure Agent service under a dedicated domain account set on the service's Log On tab, not a personal account, and grant it only the file shares it needs.
• Network: the agent connects outbound on port 443. Allow only the IDMC domain names or IP ranges for your POD (identified from your service URL, for example usw3.dm-us.informaticacloud.com is POD USW3), and route through your proxy if required; the agent supports BASIC, DIGEST and NTLMv2 proxy authentication.
• Endpoint tooling: Informatica advises excluding the agent's apps directory from security scans, because scanning can interfere with it. Compensate with file integrity monitoring and tight host access rather than leaving the host unwatched.
• Groups: place agents in Secure Agent groups by environment and data sensitivity so production credentials only run on production hosts.
• Updates: keep agents on the current version and apply operating system patches; verify installer checksums using the method in Informatica's REST API reference.

Connection credential storage

For most organisations the stronger pattern is Informatica Cloud storage plus an external secrets manager. In Settings, Security, select Enable Secret Vault, choose AWS Secrets Manager (role based on an EC2 hosted agent, or access key), Azure Key Vault (client ID, client secret, tenant ID and vault URI) or HashiCorp Vault (role ID and secret ID), and test with a runtime environment whose local Secure Agent runs the SecretManagerApp service. Then edit each connection, select Use Secret Vault and tick each credential property to fetch from the vault. Informatica documents secrets manager retrieval through local Secure Agents, so run vault backed connections on local agents. Prefer the AWS role based option where agents run on EC2, so there is no static key to protect. See the Secrets Management Guide.

Connection accounts and API use

• One account per connection: each IDMC connection should use its own least privilege account in the target system, owned by a named team, so a single credential exposure has a bounded blast radius.
• Integration users: REST API automation authenticates as an IDMC user and inherits its roles. Create dedicated integration users with narrow roles and vault their credentials; prefer the JWT authentication type with its short default expiry.
• Elastic runtime image tokens: tokens used to pull runtime images are managed by the Elastic RTE Dev Ops Engineer role; store and rotate them like any registry credential.

These connection and integration accounts are non-human identities. The NHI Authentication Guide covers credential types and rotation.

PowerCenter modernisation notes

Moving PowerCenter assets to Cloud Data Integration with CDI-PC follows a documented process: register the domain, create a repoint configuration, assess the repository, create a Connection Map and conversion properties, convert assets and update metadata. Security points to plan for:

• Parameter files: the process recommends copying PowerCenter parameter files to a shared location. Check them for embedded connection details first and restrict that share to the migration team.
• Connection Map: map old connections to new IDMC connections that use fresh least privilege accounts and vault backed properties, rather than reusing legacy shared credentials.
• Runtime placement: decide which Secure Agent groups will run converted workflows before cut-over, so production credentials are never loaded onto migration or test agents.
• Decommissioning: retire PowerCenter service and connection accounts once workflows are proven in IDMC.

Logging and detection

In Administrator, Logs, the Security Logs view records user authentication (sign-in and sign-out), Secure Agent events such as creation and updates, organisation updates and who made each change, retained for 400 days. The asset log records creating, copying, updating and deleting assets, permission changes and licence events, retained for 90 days. If your retention policy is longer, plan how you will keep these records outside IDMC, and correlate them with host and vault logs.

Metrics to track: percentage of users signing in through SAML; number of Admin and Key Admin holders; percentage of sensitive connections using Use Secret Vault; Secure Agents on the current version; agents per group outside their approved environment (target zero); days since the last role review. For detection content see the Detection Engineering for Non-Human Identities Guide.

Hardening baseline

1. Identity: configure SAML with Map SAML Groups and Roles and SCIM 2.0 where available; keep one or two native break glass admins with MFA.
2. Authentication properties: 12 character minimum, mixed character types, no reuse, MFA on, trusted IP ranges on, JWT authentication.
3. Roles: restrict Admin and Key Admin, keep Designer out of production for most users, and use custom roles for narrow duties.
4. Agents: dedicated hosts and service accounts, non-root on Linux, outbound 443 to your POD only, grouped by environment, patched and monitored.
5. Credentials: Informatica Cloud storage with an external secrets manager for sensitive properties; least privilege accounts per connection.
6. Logging: grant Audit Log - View to security, review security and asset logs, and collect agent host and vault logs.

Testing and rollback: trial SAML role mapping and trusted IP ranges in a sub-organisation or non-production org first, with a native admin session open, so a mapping error cannot lock everyone out. Move connections to Use Secret Vault one at a time and test each with its runtime environment; to roll back, clear Use Secret Vault on the connection, and only clear Enable Secret Vault once no connection uses it. Back up connection properties after any storage location or key change, as Informatica recommends.

Common misconfigurations

• Agent on a shared server: the Secure Agent shares a host with other applications and users, so anyone with host access can reach its data directory and connections.
• Personal service log-on: the Windows agent service runs as an engineer's domain account, breaking jobs when they leave and granting their file access to every job.
• Broad Designer in production: most users can edit production connections directly instead of deploying through a controlled path.
• Native users everywhere: SAML is configured but most users still sign in natively, bypassing identity provider MFA and leaver processes.
• Unmapped SAML groups: mapping is enabled but key groups are not mapped, so users get no role or default to a manually assigned broad one.
• Shared migration credentials: the Connection Map repoints PowerCenter connections to IDMC connections you choose, so if those IDMC connections reuse the old PowerCenter accounts, old and widely known passwords stay alive.

Framework mapping

Practitioner checklist

• Inventory Secure Agents, their hosts, service accounts and groups; remove any agent outside an approved environment.
• Run Linux agents as a dedicated non-root user and Windows agents under a dedicated domain service account.
• Restrict agent egress to port 443 and your POD's domains or IP ranges.
• Choose Informatica Cloud storage and enable an external secrets manager for sensitive connection properties.
• Give every connection its own least privilege account with a named owner.
• Enable SAML with Map SAML Groups and Roles, plus SCIM 2.0 where available; keep native users to break glass.
• Set MFA, trusted IP ranges, a 12 character password policy and JWT authentication.
• Limit Admin, Key Admin and secrets manager privileges to a named few and review quarterly.
• Review security and asset logs and alert on new agents, setting changes and connection edits.
• For PowerCenter migrations, review parameter files and issue fresh credentials through the Connection Map.

Standards and references

• Informatica: Authentication properties
• Informatica: Connection properties storage
• Informatica: Secrets manager configuration
• Informatica: Installing Secure Agents
• Informatica: Cross-service roles
• Informatica: User management with SAML authentication and authorization
• Informatica: Event monitoring
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: ETL and ELT Pipeline Security Guide · Secrets Management Guide · SAML Security Guide · Data Security Guide