1. How the IBM‑designed process works today

As confirmed through IBM documentation and previous IBM Support interactions:

1. Credentials must be generated externally, outside the Integration Server, in a separate container.

2. Each Integration Server can attach one and only one Vault ZIP credential archive.

3. The ZIP file must contain all credentials required by that specific Integration Server.

4. Any credential change forces the following:

   • ZIP file must be regenerated.

   • Configuration must be re‑applied.

   • Integration Server must be restarted.

The client is fully aligned with this IBM‑recommended process.

2. Core Problem

2.1 ACE requires one Vault ZIP per Integration Server

Because each server has its own credential set and Vault ZIPs do not support dynamic credentials:

• Each Integration Server requires its own ZIP file.

• With ~100 Integration Servers, the platform requires ~100 unique ZIPs.

This design becomes unmanageable at scale.

2.2 Platform‑level credentials must be copied into every ZIP

Several credentials are global across all Integration Servers:

• Shared SQL Database credentials

• Shared Kafka credentials

• Shared Object Store / Blob Storage credentials

• Other cluster-level secrets

Today these global credentials must be duplicated into every Vault ZIP.

Impact:
If a shared credential is rotated (e.g., password changes every 90 days):

• ~100 ZIP files must be regenerated

• All ~100 Integration Servers must be updated

• All ~100 Integration Servers must restart

This creates a multiplicative operational burden.

2.3 Credential rotation becomes operationally unmanageable

When any shared credential changes:

• All Integration Server Vault ZIPs must be recreated

• All Integration Servers must restart

• This results in:

  • Very high operational workload

  • Long deployment cycles

  • Platform-wide downtime

  • Significant risk during rotation events

DSV considers this approach unsustainable and not production‑viable at scale.

2.4 ACE restarts even for single‑flow credential changes

Even when only one flow requires a credential update:

• The entire Vault ZIP must be regenerated

• The entire Integration Server restarts

• All flows restart unnecessarily

This contradicts earlier IBM roadmap communication (2024/2025) indicating that ACE v13 would avoid restarts for credential updates.

Yet, with Vault ZIPs, restarts remain required.

2.5 No support for multiple Vault ZIPs per Integration Server

The ideal architecture the client wants:

• One ZIP for platform‑level credentials

• One ZIP for server‑specific / flow‑specific credentials

However, ACE does not support multiple Vault ZIPs.

This forces all credentials—global + local—into a single ZIP, which directly causes the operational explosion described above.

3. Requested IBM Support Actions

A. Confirm whether the current behavior is a product limitation or intended design.

B. Provide any supported mechanism to:

• Avoid Integration Server restarts for credential updates

• Separate platform-level credentials from application-specific ones

• Reduce or eliminate ZIP regeneration for each credential rotation

• Support multiple Vault ZIPs per Integration Server

• Support dynamic or external credential resolution without forcing restarts

C. If no current solution exists, escalate as a product enhancement request.

The client cannot sustainably operate a platform where every credential rotation requires manual recreation of ~100 Vault ZIPs and restarts of all Integration Servers.

4. Business Impact

This design limitation:

• Causes downtime across multiple mission‑critical systems

• Makes mandatory password rotation policies nearly impossible

• Introduces significant operational risk during production updates

• Severely limits the scalability of ACE for large enterprises

DSV views this as a critical blocker for long‑term adoption of ACE in a high‑scale environment.