Trust Condition Maintenance: why it changes everything about application maintenance

When a system “works”, it processes requests, returns the right responses, does not throw errors. That is the operational definition of classic application maintenance. And it is insufficient.

A system can “work” perfectly in the functional sense, while simultaneously:

• Being vulnerable to a critical CVE discovered three months ago
• Carrying a dependency whose licence has changed and creates a legal risk
• Having logs that no longer allow an incident to be reconstructed
• Using a deprecated encryption algorithm that will be broken in two years
• Gradually drifting from its security baseline without anyone noticing

Trust Condition Maintenance (TCM) is the response to this reality: maintaining the security, compliance and control of a system over time, not just its availability.

Classic application maintenance and its limits

Classic application maintenance typically covers:

• Bug fixing
• Minor functional updates
• Availability and performance monitoring
• User support

This is necessary. It is not sufficient for critical systems in regulated environments or with high cyber exposure.

The fundamental problem: classic maintenance is reactive. It responds to visible events: an error, a user complaint, a crash. It does not see latent risks that have not yet produced a symptom.

The cyber landscape has changed fundamentally. Vulnerability exploitation cycles have compressed: between the publication of a CVE and the first exploits in production, delays have gone from weeks to days, sometimes hours. A reactive security posture is structurally behind the attack.

What TCM covers in addition

Vulnerability monitoring and management

Every software dependency is a potential risk vector. A perfectly healthy library last month may be compromised today (supply chain attack like Log4Shell, like xz-utils).

TCM includes:

• SBOM (Software Bill of Materials): exhaustive and up-to-date inventory of system components, including libraries, frameworks, containers, third-party modules
• Continuous CVE monitoring: automated correlation between the SBOM and newly published vulnerabilities (NVD, ANSSI, CERT-FR)
• Prioritised remediation process: classification of vulnerabilities by criticality and actual exploitability, patching plan with defined SLAs

The question is not “do we have vulnerabilities?” (the answer is always yes). The question is “which ones are exploitable in our context, within what timeframe do we need to address them, and how?”

Maintaining regulatory compliance

A system can be GDPR-compliant at the time of its deployment and no longer be so 18 months later if the regulatory context has evolved.

TCM integrates regulatory monitoring adapted to the sector: new CNIL guidelines, DORA evolutions, new AML/CFT requirements, updates to ANSSI frameworks. With each significant development, a gap analysis assesses the impact on the system and, if necessary, triggers a compliance workstream.

This is particularly critical in the financial and health sectors, where regulatory requirements evolve frequently and where the cost of non-compliance is high (sanctions, loss of accreditation, reputational risk).

Monitoring security drift

Systems drift from their security baseline over time, often invisibly:

• A service account created for a one-off project, never deleted
• A port opened for a test, never closed
• Overly broad rights granted during an incident, never reviewed
• A security configuration modified to unblock a situation, never reverted

Remediating this drift requires:

• A documented configuration baseline at initial deployment
• Regular compliance scans comparing current state against the baseline (CIS Benchmarks, STIG depending on context)
• A periodic rights and access review process (Privileged Access Review)

Reviewing secrets and credentials

Secrets (API keys, certificates, configuration secrets) have a lifespan. Certificates expire. Unrotated API keys can be compromised.

TCM includes:

• Inventory of secrets with expiry dates
• Proactive rotation before expiry (not in an emergency on the day)
• Detection of hardcoded secrets in source code (git-secrets, truffleHog)
• Monitoring of compromise alerts from third-party platforms (Have I Been Pwned APIs, GitHub alerts)

Maintaining auditability

A system whose logs do not allow an incident to be reconstructed is a non-auditable system. And a non-auditable system is not compliant with the regulatory requirements of most sensitive sectors.

TCM monitors:

• Log integrity: are logs complete, consistent, unalterable?
• Coverage of logged events: are all significant actions traced?
• Retention period: are logs retained in accordance with regulatory obligations?
• Exploitability: in the event of an incident, can the timeline be reconstructed in a reasonable time?

TCM on a legacy system

TCM takes on a particular dimension on legacy systems. Two dynamics accumulate:

Security debt: older systems carry components whose security support has expired. Java 8 end-of-life, OpenSSL in an obsolete version, libraries without an active maintainer. Each unmaintained component is a potentially unpatched attack surface.

Loss of documentary control: on a system ten years old, the original documentation has often disappeared, the initial developers have left, and nobody knows exactly what a given module does or why a certain configuration is the way it is. This loss of control makes any intervention risky.

TCM on a legacy system therefore often begins with a reconstruction effort: component mapping, configuration reverse engineering, re-documentation of flows. This is an investment, but it is the prerequisite for any capacity to react quickly to a vulnerability.

How TCM is organised

A rhythm of continuous monitoring

TCM is not an annual audit. It is permanent monitoring with differentiated rhythms:

• Continuous: CVE monitoring, log monitoring, configuration drift alerts
• Weekly: review of alerts, status of ongoing remediations
• Monthly: security health report, key metrics (number of open CVEs by criticality, average remediation time)
• Quarterly: rights and access review, incident response procedure test
• Annual: penetration test, full security baseline review

Defined remediation SLAs

Vulnerability prioritisation must produce concrete commitments:

These SLAs are contractual commitments in a serious TCM arrangement.

Decision-oriented reporting

TCM reporting is aimed at decision-makers who are not necessarily technical. It must answer three questions:

• Where are we? (current security posture, compared to the previous period)
• What has been addressed? (remediations carried out, compliance maintained)
• What remains to be addressed? (action plan, prioritisation, resources needed)

Conclusion

Application maintenance ensures your system functions. TCM ensures your system is trustworthy, for your users, your regulators, and yourself.

In a context where cyberattacks specifically target poorly maintained systems, where regulators require evidence of continuous control, and where the loss of trust of a client or partner can be irreversible, this distinction is no longer academic. It is operational.

Do your critical systems have a TCM arrangement commensurate with their exposure? Let’s assess your situation.