English 
French 
Dutch 
The metadata manipulation problem that puts compliance, litigation and evidence preservation at risk
There is a question that rarely gets asked during a DMS procurement, and it should be: can your system prove, beyond reasonable doubt, that a document was archived on the date it claims? Not just assert it. Prove it.
For most organisations, the honest answer is no. The creation date and archival date stored in virtually every mainstream Enterprise Content Management and Document Management System is a plain database value. It can be changed. In most cases, it can be changed silently, without leaving a trace in the audit log, by anyone with sufficient database access. That includes database administrators, system administrators and, in some cases, application-level superusers.
This is not a theoretical risk. It is a documented reality across the entire ECM industry, acknowledged in vendor forums, migration guides and developer documentation. Yet the implications for organisations that rely on these systems for compliance archiving, litigation support and regulatory evidence are rarely spelled out clearly.
Why the archival date matters
When a document is produced as evidence, the date it was created or received is often as important as its content. A contract, an invoice, a risk assessment, an internal approval: each of these only has evidential value if its provenance can be established. Regulators, courts and auditors do not simply take your word for it that a document existed on a given date. They expect a chain of custody.
Mainstream DMS and ECM platforms store their metadata in relational databases. That is not in itself a problem. The problem is that nothing prevents that data from being modified at the database layer, bypassing all the access controls and audit trails the application enforces.
A tool used outside its design envelope
Now, it is important to be fair to the vendors here. This is not a story about negligence or deception. Document management systems were not designed to be evidence preservation systems, and the vendors never claimed they were.
The original purpose of a DMS was to manage the lifecycle of working documents: routing drafts for review, tracking revisions, controlling which version was current, managing approval workflows. A contract goes through ten drafts before it is signed. A quality manual needs a formal review cycle every year. An engineering drawing must be checked before it can be released to production. These are the problems DMS platforms were built to solve, and they solve them well. The creation date in this context is a convenience feature, a way to order search results and understand when work started, not a legal instrument.
Over time, organisations quite reasonably looked at their DMS investment and asked whether it could also serve as a long-term archive. The files were already there. The metadata was already there. The retention policies could be configured. It seemed like a natural extension of the same system, and vendors added archiving-adjacent features to accommodate the demand.
What did not change was the underlying architecture. A DMS is built as a tiered system: a relational database holds metadata, a file system or object store holds the actual files, and the application layer sitting above them enforces the rules. That tier separation is fundamental to how these systems work. It also means that the metadata layer is never more than a database query away from anyone with direct access to the infrastructure. The application layer’s protections are real, but they are not the only path in.
Evidence preservation requires a different architectural guarantee: one where the timestamp is not merely recorded by the system, but anchored outside it, by an independent authority, in a way that cannot be undone without detection. That guarantee was simply never part of the DMS design brief. The vendors are not at fault for not building something they were never asked to build. The risk arises when organisations deploy these systems for a purpose they were not designed to fulfil, without understanding what that gap means in practice.
The pattern across every major platform
OpenText Documentum
Documentum is perhaps the most widely documented case. The r_creation_date attribute on a dm_sysobject is treated as a read-only system field by the application layer, and neither standard DFC/DQL operations nor the WebTop client allow it to be changed. But the underlying dm_sysobject_s table in the Oracle or SQL Server database is fully accessible to anyone with DBA credentials. Practitioners have confirmed in OpenText’s own developer forums that calling exec_sql to update r_creation_date directly in that table works without any issue and has been used routinely in large-scale document migrations.
The same applies to r_modify_date. A French developer blog notes that the only way to modify r_modify_date by bypassing Documentum entirely is to update it directly in the dm_sysobject_s table, and provides the exact SQL to do so.
OpenText Extended ECM (xECM / Content Server)
OpenText Content Server, the foundation of xECM, exhibits the same architecture. While the application server ignores attempts to set CreatedDate through normal API calls, this protection only exists at the application layer. An OpenText developer forum thread discussing data migration confirms that the Object Importer tool itself explicitly uses direct SQL to enable date override on import, and that hacking the system at the database level is possible, though unsupported.4 Any organisation that grants DBA-level access to its SQL Server or Oracle backend has implicitly granted the ability to rewrite these values.
IBM FileNet P8
IBM has published a technote specifically addressing whether DateCreated and Creator can be modified on an IBM FileNet P8 Content Engine object store. The very existence of this knowledge base article tells you the scenario is well known. Further, IBM’s documentation on the FileNet permission model includes a specific access right called “Modify certain system properties,” which, when granted to a user, allows those normally read-only system date fields to be updated through the standard API. On-premises deployments where this right is misused, or where the underlying database is accessible, face the same risk as every other platform in this list.
IBM CMOD (Content Manager OnDemand)
IBM CMOD is the most transparent of all the platforms about this risk. The CMOD community wiki’s own documentation for the arsdoc update command states explicitly: “The alteration of index data as a part of normal processing creates a risk that your system will not be considered a reliable archive, and in a court of law, the accuracy of the system could be called into question.ā
CMOD also has a structural vulnerability specific to its architecture. Dates have historically been stored as integers representing the number of days since 1 January 1970 UTC, meaning they sit in plain database tables as simple numeric values with no cryptographic protection.
Microsoft SharePoint
SharePoint is arguably the most permissive platform of all. While the browser-based UI does not expose the Created field for editing, this protection is entirely superficial. Microsoft’s own documentation and community guides describe in detail how to update Created, Modified, Created By and Modified By fields using PowerShell and the Client-Side Object Model (CSOM). A widely read guide on SharePoint Diary demonstrates exactly how to set these system fields to any arbitrary value for any document in a library. The author notes that they do not recommend manipulating these metadata fields “unless really required” but confirms the capability is fully functional. SharePoint Online is no different: the same PowerShell approach works against Microsoft 365.
Alfresco (Hyland)
Alfresco stores document metadata, including the cm:created property, in a relational database, with the metadata described in official documentation as stored in the database separately from the content files. While cm:created is marked read-only through the CMIS interface, the Alfresco developer hub contains a straightforward workaround: by calling policyBehaviourFilter.disableBehaviour() on the auditable aspect, a developer can then call nodeService.setProperty() to set the creation date to any value. For large-scale imports, Alfresco’s own official documentation notes that the Bulk Import tool turns off the automatic system management of these properties so the original file dates can be preserved, meaning the system itself provides an official mechanism for overriding them.
M-Files
M-Files stores vault data in either Firebird or Microsoft SQL Server. Its developer documentation acknowledges that some property values are built-in and automatically maintained, such as the creation date, but that setting properties from VBScript or the Vault Application Framework may cause the audit trail to become broken unless care is taken. The vault database engine is a standard SQL Server instance: any DBA with access to that instance can issue UPDATE statements against vault tables directly, with no application-layer mediation. M-Files explicitly documents SQL Server as a supported and recommended database engine for large deployments.
Hyland OnBase
OnBase is built on SQL Server and follows the same pattern. Hyland’s own documentation explicitly warns against making direct modifications to the OnBase database schema or data.17 The warning itself is the proof: direct database access is possible, and the application relies on administrators choosing not to exercise it rather than on any cryptographic guarantee that prevents tampering.
Nuxeo (Hyland)
Nuxeo is, I have to say, the most candid platform of all about its database architecture. Its official VCS (Visible Content Store) documentation states: “Because data is transparently stored in SQL tables, it is very easy to have a look at them and understand exactly what is going on. For big data migration you can use direct SQL injection.ā The dc:created field is a regular column in those SQL tables. Nuxeo explicitly positions direct SQL access as a feature for migration scenarios, which means the “protection” of this field is entirely contingent on nobody choosing to use that feature for less legitimate purposes.
Laserfiche
Laserfiche’s community forum contains a thread that precisely illustrates the situation. A user asks whether the creation date of an entry can be modified. The response is direct: “By design, there is no supported way to change an entry’s creation date. The only way to do it would be by updating the toc table directly.” The same community confirms that metadata fields are “just data in a database” and that SQL updates are technically feasible, though unsupported.
SAP ArchiveLink
SAP ArchiveLink stores the logical assignment between application documents and their archived counterparts in standard SAP database tables, most notably the TOA01 table family. These tables are plain relational database tables within the SAP system, accessible to anyone with SAP basis-level or underlying database access. The archive date recorded in these tables is a standard field with no independent cryptographic anchoring.
Every homebrew system
The platforms surveyed above represent only the commercial market. Many organisations operate custom-built or heavily customised document management systems developed in-house or by specialist integrators. These systems are not exempt from the same vulnerability. They are, if anything, more exposed.
Every DMS, whether commercial or bespoke, is built on the same architectural principle: a relational database holds metadata, a file system or object store holds files, and an application layer enforces access rules above both. That is not a design choice peculiar to any specific vendor; it is the natural consequence of how enterprise software is built. A custom system built on PostgreSQL, SQL Server, MySQL or Oracle has exactly the same exposure. The creation date is a column in a table. Anyone with database credentials can change it.
Custom systems frequently lack even the partial protections that commercial platforms provide. There is no vendor-maintained audit of database schema changes, no support community documenting known manipulation paths, and often no separation between the application administrator role and the database administrator role. The person who can restart the application is the same person who can run a direct SQL UPDATE. The organisation that built its own DMS has built its own vulnerability, along with everything else.
How this can be exploited
It is worth being explicit about what “exploitable” means in practice, because the risk is not only about bad actors within an organisation.
The disgruntled administrator scenario. A DBA or system administrator with legitimate access to the underlying database can modify archival timestamps on documents relating to a dispute, a regulatory investigation or an internal audit. Because the change is made at the database layer, it bypasses the application’s audit trail entirely. There is no log entry.
The migration scenario as cover. Document migrations are routine in large organisations. Every platform discussed above has a documented pattern of using direct database access or privileged API calls to preserve original dates from source systems. This creates a legitimate-seeming justification for direct database modifications. An insider can claim that a suspicious date discrepancy was the result of a migration issue rather than deliberate manipulation.
The legal dispute scenario. When an organisation is involved in litigation and needs to produce documents, the other party’s lawyers may challenge the authenticity of timestamps. Without independent cryptographic proof that a document was archived on a given date, the organisation cannot demonstrate that the metadata has not been altered since the dispute arose. All it can offer is the system’s own word, and the system’s word can be changed.
The regulatory audit scenario. Under GDPR, MiFID II, DORA, the Belgian Digital Act and a growing number of sector-specific regulations, organisations must demonstrate that documents were created, received or archived within specified timeframes. If the dates stored in a DMS can be silently modified, those demonstrations are hollow.
References
OpenText Developer Forums (2011). To set r_creation_date manually?
https://forums.opentext.com/forums/developer/discussion/150200/to-set-r-creation-date-manually
JavaBlog.fr (2017). Documentum: Locale, Date Storage, Update of Last Modification Date / Last Modifier (r_modify_date).
OpenText Developer Forums (2013). Upload Document and Change Create Date.
IBM Support (various). Modify DateCreated and Creator fields in IBM FileNet Content Engine object store (OS).
IBM Support (2012). Unable to export and import items from one object store to another.
https://www.ibm.com/support/pages/unable-export-and-import-items-one-object-store-another
CMOD.wiki. arsdoc update.
https://cmod.wiki/index.php/arsdoc_update
CMOD.wiki. Date and Time formats in Content Manager OnDemand.
https://cmod.wiki/index.php/Date_and_Time_formats_in_Content_Manager_OnDemand
SharePoint Diary (2016). SharePoint Online: Update Created By / Modified By, Created / Modified Field Values using PowerShell.
Alfresco Documentation. Set up content stores.
https://docs.alfresco.com/content-services/7.0/admin/content-stores/
Alfresco Hub (2018). How to modify the creation date?
Alfresco Documentation. Content Model Extension Point.
https://docs.alfresco.com/content-services/latest/develop/repo-ext-points/content-model/
M-Files Developer Documentation. Vault Structure.
https://developer.m-files.com/Getting-Started/Vault-Structure/
M-Files User Guide. Configuring Microsoft SQL Server databases.
https://userguide.m-files.com/user-guide/latest/eng/configuring_sql.html
Hyland Support. Database Reference Guide: Modifying the Database Schema.
Nuxeo Documentation. Visible Content Store (VCS)
https://doc.nuxeo.com/nxdoc/vcs/
Laserfiche Answers (community forum). Modifying the creation date.
https://answers.laserfiche.com/questions/49430/Modifying-the-creation-date
Laserfiche Answers (community forum). Feature Request: Metadata bulk update tool.
https://answers.laserfiche.com/questions/190619/Feature-Request–Metadata-bulk-update-tool
SAP Knowledge Base Article 1900309. HowTo: Archiving ArchiveLink connection entries from tables TOA01.
https://userapps.support.sap.com/sap/support/knowledge/en/1900309
