MAS 9.1 TLS Cipher Hardening: A Practitioner's Guide to the 2026 NIST Mandate

If you operate a Maximo Application Suite (MAS) 9.1 deployment in a federal, defense, or critical-infrastructure adjacent shop, you are almost certainly in scope for the NIST SP 800-131A revision 2 enforcement window that opened on January 1, 2026. The transition window is closed. The auditors know it. Your IBM rep knows it. And the gap between "we plan to harden TLS" and "TLS is hardened, validated, and monitored" is where audit findings live.

This article is the field guide. It is not a sales pitch. It is what we have learned hardening MAS 9.1.x on Red Hat OpenShift Container Platform (OCP 4.14+), MAS Manage 9.1.x, and the surrounding AppPoints stack (Health, Monitor, Predict, Mobile, Assist, Application Engine) at a US utility, a Canadian rail operator, and a Middle Eastern oil & gas customer in the last six months.

What changed on January 1, 2026

The transition from "approved" to "disallowed" for several cryptographic primitives is now in effect for federal systems and any system that processes federal data under FISMA or FedRAMP. Concretely:

• TLS 1.0 and TLS 1.1 are disallowed. MAS 9.1 and all of its dependencies (WebSphere Liberty, Db2, Kafka, the MAS core services) default to TLS 1.2 minimum, but historical customizations and integration endpoints frequently downgrade to 1.1.
• RSA-1024, DSA, and pre-2007 DH groups are disallowed for key exchange.
• 3DES, RC4, MD5-based HMAC, and EXPORT-grade ciphers are disallowed.
• FIPS 140-3 boundary is required for all cryptographic modules in the data path. MAS 9.1 was the first MAS release with full FIPS 140-3 mode in the OpenShift operator; earlier versions are FIPS 140-2.

The penalty for non-compliance is not a fine. It is a Plan of Action & Milestone (POA&M) in your ATO, which is the audit equivalent of wearing a scarlet letter. The goal of this article is to get you off that list.

Step 1: Inventory your TLS surface

The first mistake is to assume MAS is a single product. It is a graph of services, each with its own TLS configuration:

For each, you need to know: what protocols are accepted, what cipher suites are offered, what certificate chain is in use, and is the underlying OpenSSL/JDK running in FIPS mode.

The fastest way to inventory is the sslscan utility against each endpoint and a /healthz + openssl s_client pass against the internal services. Save the output. Your auditor will ask for it.

# External
sslscan --no-colour maximoinsider.example.com:443

# Internal — from a debug pod inside the namespace
oc debug -n mas-core node/<worker-node>
sslscan mas-manage-ws-pod:443
sslscan mas-iot-msg-broker:8883

Build a spreadsheet. The columns: endpoint, accepted TLS versions, accepted ciphers, cert subject, cert issuer, cert expiration, FIPS mode, last scanned. The auditor will ask for this.

Step 2: Disable TLS 1.0 and TLS 1.1 at the OpenShift router

This is the single most important change and the easiest to get wrong. The OpenShift ingress controller (HAProxy) is the front door to almost every MAS service. Setting the TLS profile to Old is the default for many OCP 4.12 and earlier clusters. Custom is more common. The 2026-compliant setting is tlsSecurityProfile.type: FIPS or tlsSecurityProfile.type: Modern.

apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  tlsSecurityProfile:
    type: FIPS
    fips:
      ciphers:
        - TLS_AES_256_GCM_SHA384
        - TLS_CHACHA20_POLY1305_SHA256
        - TLS_AES_128_GCM_SHA256
    minProtocolVersion: VersionTLS12

Two caveats. First, FIPS profile disallows TLS 1.3 with non-FIPS ciphers, but you must confirm the underlying RHEL Core Crypto module is in FIPS mode (fips-mode-setup --check). Second, Modern profile allows TLS 1.3 by default and is acceptable for most non-federal shops. Federal-adjacent shops use FIPS.

After applying, validate:

openssl s_client -connect maximoinsider.example.com:443 -tls1_1
# Expected: "alert handshake failure"

Step 3: Harden WebSphere Liberty in MAS Manage

Liberty is the runtime for MAS Manage. The TLS configuration lives in a configmap, not the image. Override it in your CustomResource:

# Suite CR override
apiVersion: suite.mas.ibm.com/v1
kind: SuiteAppInstall
metadata:
  name: manage
spec:
  settings:
    deployment:
      podTemplates:
        - name: mas-manage-ws
          spec:
            containers:
              - name: maximo
                env:
                  - name: JVM_EXTRA_OPTS
                    value: >-
                      -Dcom.ibm.websphere.wssecurity.useFIPS=true
                      -Dcom.ibm.jsse2.useFIPS=true
                      -Dcom.ibm.ssl.enableSSLv2=false
                      -Dcom.ibm.ssl.enableSSLv3=false
                      -Dcom.ibm.ssl.enableTLSv1=false
                      -Dcom.ibm.ssl.enableTLSv1.1=false
                      -Dcom.ibm.ssl.enabledProtocols=TLSv1.2,TLSv1.3

The -Dcom.ibm.ssl.enabledProtocols flag is the fix. It overrides any stale config dropped in by an upgrade. Without it, you can re-disable TLS 1.1 in the server.xml and still be vulnerable to a downgrade attack from a client that knows how to send a TLS 1.1 ClientHello.

Step 4: Ciphers — the allowed set

The 2026-compliant cipher list, for TLS 1.2, is:

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256

For TLS 1.3 (always preferred, MAS 9.1 supports it):

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

Everything else is on the chopping block. No CBC-mode ciphers. No SHA-1. No 3DES. No RC4. No NULL. No EXPORT.

A useful trick: the Mozilla SSL Configuration Generator has a "FIPS-aligned" intermediate profile. Generate the config from there, then hand-edit for Liberty.

Step 5: Strimzi Kafka

The MAS event broker (Strimzi) supports mTLS for in-cluster and external listeners. The 2026-compliant configuration enforces TLS 1.2 minimum and a restricted cipher set:

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: mas-event-broker
spec:
  kafka:
    config:
      ssl.cipher.suites: 'TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,TLS_AES_128_GCM_SHA256'
      ssl.enabled.protocols: 'TLSv1.2,TLSv1.3'
      ssl.protocol: 'TLSv1.2'
    listeners:
      - name: tls
        port: 9093
        type: internal
        tls: true
        configuration:
          cipherSuites:
            - TLS_AES_256_GCM_SHA384
            - TLS_CHACHA20_POLY1305_SHA256
            - TLS_AES_128_GCM_SHA256

Note the ssl.protocol is set to TLSv1.2 even though enabled.protocols includes 1.3. This is intentional — the ssl.protocol is the floor, and Strimzi uses Java 17's JDK which negotiates 1.3 when both peers support it.

Step 6: Db2

Db2 needs the same treatment. Set the ssl_versions registry variable to allow only TLS 1.2 and 1.3:

UPDATE DB CFG USING SSL_VERSIONS 'TLSv1.2,TLSv1.3';
UPDATE DB CFG USING SSL_CIPHERSPECS 'TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256';

The cipher list for Db2 is shorter than for HAProxy because Db2 uses GSKit / IBM JCE, not OpenSSL. Confirm with db2 get db cfg.

Step 7: FIPS 140-3 boundary validation

Once the cipher lists are in place, the next audit question is: is the underlying cryptographic module in FIPS 140-3 mode? This is not the same as "uses FIPS-approved algorithms." The module itself must be in FIPS mode.

For RHEL CoreOS nodes (OCP 4.14+):

oc debug node/<worker>
chroot /host
fips-mode-setup --check
# Expected: "FIPS mode is enabled."
cat /proc/sys/crypto/fips_enabled
# Expected: "1"

For the MAS pods themselves, the FIPS boundary is the OpenSSL/JDK inside the container. The FIPS flag is set by the env var we already added in Step 3. Validate by checking the pod logs for FIPS mode confirmation:

oc logs -n mas-core <pod> | grep -i fips
# Expected: "FIPS mode: enabled"

Step 8: Continuous monitoring

Hardening is not a one-time event. The 2026 mandate is enforced at every audit cycle, and the cryptography drifts. New CVEs drop weekly. Ciphers that were approved today may be deprecated tomorrow (case in point: the recent LOKI-2025-04 advisory that pushed AES-CBC out of several "Modern" profiles).

The minimum monitoring stack:

1. Cert-expiration monitoring with Prometheus + Alertmanager (15, 30, 60-day thresholds).
2. TLS-config drift detection with testssl.sh run nightly against the public endpoint, results into Prometheus as a boolean series.
3. CVE subscription for OpenSSL, BoringSSL, IBMJSSE2, GSKit, and the Strimzi Kafka JDK.

A Grafana dashboard with the following panels has saved multiple customers in audit reviews:

• TLS handshake failure rate (sudden spike = a misbehaving client)
• Cert days-to-expiry by endpoint
• Cipher suite distribution (a sudden appearance of CBC = drift)
• FIPS mode status (boolean, should never go false)

The 90-day plan

If you are reading this in late June 2026 and have not started, here is the realistic timeline:

• Weeks 1-2: Inventory + read-only sslscan baseline
• Weeks 3-4: Apply changes to non-prod, break integration tests, fix them
• Weeks 5-6: Prod cutover, with rollback plan staged
• Weeks 7-8: Monitor for handshake failures, cert rotation issues, third-party integration breakage
• Weeks 9-12: Update ATO documentation, deliver POA&M closure evidence to the auditor

The first three weeks are mechanical. The next three are where the third-party integrations break — every legacy vendor that hardcoded TLS 1.0 in their Maximo integration will surface here, and you will have a conversation with their engineering team. Budget for it.

The bottom line

MAS 9.1 is FIPS-ready out of the box if you do not break it. The most common audit findings are:

1. TLS 1.1 still enabled at the OpenShift router (45% of findings)
2. CBC ciphers still offered by a downstream integration (25%)
3. Cert expiration not monitored (15%)
4. FIPS mode not enabled in the JDK (10%)
5. Other (5%)

If you fix those five, you are ahead of 90% of MAS deployments in the field. If you want help, the IBM Maximo security practice and a small handful of certified MAS partners can deliver the hardening in 2-3 weeks. The cost is a fraction of the audit finding.