Every bearing condition monitoring system generates data. Vibration spectra, temperature trends, health scores, alarm logs — the volume of data produced by modern monitoring platforms is substantial. But volume is not the same as evidential weight. When a bearing failure triggers a dispute between an equipment operator, a bearing manufacturer, a maintenance contractor, and an insurer, the critical question is not whether data exists. The critical question is whether any party can demonstrate that the data has not been altered since capture.
This is the problem of tamper evidence — and it is the problem that separates operational monitoring data from forensic evidence.
The Difference Between Data and Evidence
Operational data serves operational purposes. A vibration trend shows whether a bearing is degrading. A temperature alarm triggers a maintenance work order. A health score informs a scheduling decision. None of these functions require the data to be provably unmodified. If a maintenance manager looks at a trend plot and decides to schedule a bearing replacement, the integrity of the underlying data points is not in question — the manager trusts the system because they control it.
Evidence serves a different function. Evidence must be credible to parties who do not control it, did not collect it, and may have strong incentives to dispute it. In a failure investigation, every party examines the data with a specific question: could the data have been modified by a party with an interest in the outcome?
If the answer is yes — if the data was stored on systems controlled by one of the parties, transmitted through infrastructure managed by one of the parties, or processed by software maintained by one of the parties — then the evidential weight of the data is compromised regardless of whether any modification actually occurred. The mere possibility of tampering is sufficient to undermine credibility.
How Standard Monitoring Data Is Vulnerable
Most bearing condition monitoring data passes through a chain of systems, each controlled by a specific party:
Sensor to Gateway
Data flows from the sensor to a local gateway or edge device, typically installed and maintained by the monitoring vendor or the equipment operator. At this stage, raw data may be preprocessed, filtered, compressed, or aggregated. The original waveform may never leave the gateway — only derived metrics are forwarded. Any modification at this stage is invisible to downstream consumers of the data.
Gateway to Cloud
Data is transmitted to a cloud platform operated by the monitoring vendor. During transmission, data passes through network infrastructure controlled by the operator or a third-party provider. At the cloud platform, data is stored in databases managed by the vendor. The vendor has administrative access to these databases. Retention policies, data migration, and software updates all create windows in which data could theoretically be modified without detection.
Cloud to Report
When a failure occurs and data is retrieved for analysis, it is typically exported from the cloud platform by the vendor, formatted into reports, and delivered to the investigating parties. The parties receiving the report have no way to verify that the exported data matches what was originally captured at the sensor. They receive a processed artifact, not a sealed original.
At no point in this chain is there a mechanism that would make unauthorized modification detectable. The data may be perfectly accurate — but its accuracy cannot be independently verified.
What Tamper Evidence Requires
Tamper evidence is not encryption. Encryption protects data from being read by unauthorized parties. Tamper evidence protects data from being modified without detection. They are complementary but distinct properties.
A tamper-evident data system must satisfy three requirements:
1. Integrity Verification
Any party must be able to verify that the data has not been modified since the moment of capture. This typically involves cryptographic hashing — computing a fixed-length digest of the data at capture time, then storing that digest in a way that is independent of the data itself. If any bit of the data changes, the hash will not match, and the modification is detectable. The verification process must be reproducible by any party with access to the data and the hash, without requiring trust in the party that captured the data.
2. Seal Independence
The integrity seal must be independent of the system that stores the data. If the hash is stored alongside the data on the same system controlled by the same party, both can be modified simultaneously. For the seal to be credible, it must be stored or registered in a way that no single party can alter. Options include multi-party key escrow, independent timestamp authorities, or distributed registration systems where modification would require collusion among multiple independent parties.
3. Access Auditability
Every access to the sealed data must be logged in a way that is itself tamper-evident. If a party accessed the data — even read-only access — this must be recorded. In a dispute, the access log establishes who has seen the data and when, which is relevant to evaluating any claims about the data’s integrity.
Architectural Approaches
Several architectural patterns can deliver tamper evidence for bearing condition data:
Capture-Time Sealing
The strongest approach seals data at the moment of capture, before it enters any system controlled by a party to a potential dispute. The sensor node itself computes a cryptographic hash of the raw captured data and stores both the data and the hash in local, non-volatile memory. The hash is additionally registered with an independent authority or distributed to multiple parties at the time of capture. From this point forward, any modification to the data will be detectable by comparing it against the original hash.
Multi-Party Key Control
Access to the sealed data requires agreement among multiple parties. No single party — not the equipment operator, not the monitoring vendor, not the sensor manufacturer — can unilaterally decrypt, export, or release the data. This prevents any party from accessing the data privately, modifying it, and re-sealing it. It also ensures that when the data is eventually released for analysis, all relevant parties are aware of and can observe the release.
Invalidation Transparency
If any condition occurs that could compromise the integrity of the captured data — physical tampering with the sensor housing, removal of the sensor from its mounting, loss of power to the sealing mechanism — this must be recorded and made evident. A tamper-evident system does not merely protect against intentional modification; it also records any event that could cast doubt on the data’s integrity, even if no modification occurred.
Why This Changes Dispute Dynamics
When bearing failure data is tamper-evident, the dynamics of a failure dispute change fundamentally:
- Credibility is architectural, not testimonial. The data’s integrity does not depend on anyone’s testimony about what happened to it. It is verifiable by cryptographic proof. An expert witness can confirm the data is unmodified without relying on the word of any party.
- Selective disclosure is impossible. Because all parties share key control, no party can selectively release favorable data while withholding unfavorable data. The record is complete or it is nothing.
- Narratives must be consistent with physics. When the physical record is trustworthy, competing narratives are constrained by what the data actually shows. A party cannot claim the bearing was properly lubricated if the vibration data shows amplitude patterns consistent with dry running. A party cannot claim the failure was sudden if the data shows progressive degradation over hours.
- Settlement becomes rational. When both parties can see the same unmodified evidence, settlement negotiations shift from a war of attrition to a rational assessment of liability. The party whose narrative is contradicted by the physical evidence has a strong incentive to settle rather than incur further legal costs defending an untenable position.
The Standard That Should Exist
There is no current ISO or IEC standard specifically addressing tamper-evident requirements for bearing condition monitoring data. Standards like ISO 13373 (condition monitoring and diagnostics of machines) and ISO 18436 (condition monitoring and diagnostics) address data collection methodologies and analyst competency, but they do not address the evidential integrity of the data itself.
This is a gap. As bearing condition monitoring becomes ubiquitous and as the financial stakes of failure disputes continue to grow, the absence of tamper-evidence requirements means that an increasing volume of monitoring data is being generated that cannot withstand adversarial scrutiny. The data is useful for operations but insufficient for dispute resolution — which is precisely when it matters most.
Until standards catch up, the burden falls on system architects to build tamper evidence into the capture and storage architecture from the ground up. Retrofitting tamper evidence onto an existing monitoring system is architecturally difficult and forensically weak. The integrity of the data must be established at the moment of capture, not applied after the fact.
Conclusion
Tamper-evident bearing condition data is not a feature. It is a requirement for any data that will be used as evidence in a failure dispute. Standard monitoring systems, however sophisticated their analytics, cannot provide this property because they were not designed for it. They were designed to support maintenance decisions, not to withstand adversarial scrutiny.
The difference is architectural. Tamper evidence must be built into the capture mechanism, the storage mechanism, and the access control mechanism from the beginning. When it is, the data becomes something more than operational intelligence — it becomes a neutral, verifiable physical record that can resolve disputes on the basis of evidence rather than leverage.