Electronic Logbooks: France's 2024 Guidance Is Now Binding Law
8 November 2023. Meeting for its 983rd session, France's Commission centrale de sécurité (CCS), the standing committee that drafts the country's ship safety rules, takes up a draft instruction with an unambiguous title: the study and approval of electronic logbooks, or "E-BOOK". Running to barely six pages, the document sets out point by point what software must guarantee before it can replace a French ship's paper logbook, and the commission gives a favourable opinion, opens a consultation until 20 November and asks that two further questions be examined: whether signatures issued by a European agency equivalent to ANSSI, the French cybersecurity authority, should be accepted, and whether the logbook ought to be backed up to the voyage data recorder so that it can be retrieved if the ship is abandoned.
10 January 2024. The 985th session closes the study: the text returns amended on precisely those two points, and the commission approves it without reservation. Then, for the best part of three years, nothing happens — for an administrative instruction, however sound, has never carried the force of a regulation.
18 October 2026. An order dated 14 October 2026, published in the French Official Journal, inserts into the general ship safety regulations of 23 November 1987 a new article 110.9.2 devoted entirely to electronic logbooks. Read it alongside the 2024 instruction and the resemblance is unmistakable, almost word for word: what had been a methodology approved in committee has become enforceable law.
The essentials
The text: the order of 14 October 2026, published in the Journal officiel of 18 October 2026, creating article 110.9.2 of the regulations annexed to the order of 23 November 1987.
The principle: an electronic logbook is permitted, never mandatory, and only after prior approval by the CCS, a regional safety commission, or an authorised classification society.
The scope of the logbook is defined: bridge log, engine room log, radio log and annexed registers.
The key requirements: signatures compliant with the eIDAS Regulation, a named audit trail, a per-entry status field reading "pending" then "verified", encrypted offline backup, five-year retention and a declaration of conformity kept on board.
The widening: divisions 226, 228, 229 and 230 are amended, bringing fishing vessels and aquaculture vessels into a framework that had been closed to them.
For owners beyond the French register this matters for a reason that has little to do with flag, since few administrations have set down in enforceable terms what separates a piece of onboard software from a logbook that will stand up to an inspector. France now has, and the list is worth reading whatever flag a ship flies.
Before 18 October: four lines and a narrow scope
Electronic logbooks were not, in truth, new to French law, since article 221-V/28 bis of the same regulations has provided since 7 April 2017 that they may be used where the system complies with international requirements and the company has obtained the prior agreement of the competent authority. Three sentences follow, and hardly more: entered data must be protected, signatures may be electronic, and corrections are added as a note. Retention, for its part, is set at three years.
Four lines, then, for a subject that called for fifty, and a narrow field of application, since division 221 covers only passenger ships on international voyages and cargo ships of 500 gross tonnage and above. A fishing vessel operator, an aquaculture operator or a domestic coastal owner found nothing there that applied to them.
It is this double gap that the October order closes, and the way it does so deserves attention, for it moves the subject into division 110, the general provisions, which is to say the part of the regulations that applies across the board to every ship.
Three years of instruction, carried over almost verbatim
Set the two CCS minutes beside the published order and the continuity becomes plain. The minutes of 8 November 2023 already laid down the full architecture: the competent authority defined by reference to articles 14, 20 and 3-1.I of decree no. 84-810, the list of technical requirements, and a model declaration of conformity in annex. The minutes of 10 January 2024 then amended it on the two points the commission had raised, adding the recommendation to back up to the voyage data recorder and the acceptance of a signature issued by a qualified trust service provider recognised by another EU Member State, with a footnote pointing to Regulation (EU) No 910/2014.
Both amendments survived the passage into the Official Journal, where they appear unchanged in article 110.9.2, while annex 01 of the minutes, which offered a "specimen declaration", has become annex 110-A.1 of the regulations. The administration, in other words, did not rewrite its instruction in order to regulate it: it promoted it.
The practical consequence is a welcome one, since software vendors and classification societies that have been working from the 2024 instruction have nothing to redo, and the criteria against which a file will be assessed tomorrow are those that have circulated publicly since January 2024.
What article 110.9.2 actually demands of software
This is the useful part of the text, and it reads like an evaluation grid that any owner comparing solutions, under any flag, can take as it stands:
Prior approval, never self-certification. The competent authority is the CCS, a regional safety commission or an authorised classification society depending on the ship, and the application must demonstrate that every requirement below is met.
Unique, dated and chronologically numbered pages, with data protected against deletion, destruction and overwriting.
Full traceability of corrections, any amendment having to remain visible both in the system and on any printed output: nothing is erased.
Electronic signatures compliant with eIDAS, issued by a trust service provider recognised by ANSSI or by a qualified provider recognised in another EU Member State.
Role-based access control, with unique personal credentials, and an audit trail recording for each access whether the user entered, viewed or modified data.
A status field for every entry, showing "pending" or "awaiting verification" until the master validates it and "verified" thereafter; an entry amended after validation reverts automatically to pending, and the system must prompt the master that a fresh verification is due.
An additional authentication factor for the master's verification, distinct from ordinary log-in.
Automatic offline backup on every change, encrypted, read-only, transferable and printable, the text further recommending backup to the VDR and inviting owners to provide alternative power sources.
Retention of at least five years after the last entry, it being specified that where a ship is sold it is the seller who keeps the logbooks ashore.
A paper copy certified true by the master, producible on demand, identifying the software and its version number.
A written declaration from the competent authority kept on board, following the model at annex 110-A.1 and available at statutory surveys and inspections.
Crew familiarisation procedures established by the owner: the text is explicit on this, having the tool is not enough, the crew must also be able to use it.
One provision is easily missed and deserves flagging, because it binds the vendor as much as the owner: software updates must themselves be approved by the competent authority, and must neither lose existing records nor render them illegible. A vendor shipping continuous releases therefore has to plan its delivery cycle accordingly.
Who is covered, and why fishing changes status
The order does more than write the framework, since it also opens, article by article, the divisions that had no access to it. Division 226 (fishing vessels from 12 to 24 metres) and division 230 (aquaculture vessels under 24 metres) now provide that logbook entries are made "in ink or electronically, subject to article 110.9.2", while division 228 (fishing vessels of 24 metres and above) receives equivalent wording and division 229 does the same for cargo ships in domestic trade.
For fishing this is a change of kind rather than of degree: an operator wanting to abandon the paper register previously had no regulatory basis to point to, and now has one. That does not spare them the approval process, admittedly, but the door exists, and it is precisely the same door as for a cargo ship.
Why many fleets are not ready
The obstacle is not technical but documentary, and it rests on a widespread confusion between three very different things: having a digital tool on board, keeping a logbook, and being able to produce a logbook that will hold up.
Many fleets already record events in a shared spreadsheet or an in-house application. Yet a spreadsheet has no audit trail, no status field, no qualified signature and no encrypted read-only backup, and it can be altered without leaving a trace, so that it may serve operations well enough while satisfying none of the requirements set out above. Maintenance teams that abandon spreadsheets rarely do so for regulatory reasons and almost always for reasons of reliability, the two motives converging here.
The second blind spot is retention, for five years is a long time, and it is precisely the period over which an owner may be asked to demonstrate, after a casualty or during an inspection, what was done on board and when. Port state control detentions rest, after all, far more often on an inability to produce evidence than on an observed material defect.
What changes in day-to-day operation
Submit an approval file to the CCS, a regional safety commission or the ship's classification society before abandoning paper.
Check the signature provider, which must be recognised by ANSSI or qualified in another Member State: an in-house signature or a simple PIN will not meet the eIDAS requirement.
Keep the declaration of conformity on board, in the form of annex 110-A.1, naming the ship, the manufacturer, the supplier, the installer, the software name and version and the installation date.
Write the familiarisation procedure and fold it into the safety management system, alongside the other procedures required by the ISM Code.
Plan for degraded mode — system failure, loss of network, backup power — and for the ability to produce a certified paper copy within the hour if an inspector asks.
Organise shore-side retention, including the case of a sale, where the obligation stays with the seller.
These checks are added to, rather than substituted for, the rest of the regulations, and article 110.9.2 closes on a reminder that leaves little room for interpretation:
Using an electronic logbook and relying on those records in no way relieves owners of the obligation incumbent upon them under the rules to keep the registers properly and to present them at inspections.
The sentence preceding it is just as blunt, providing that an electronic logbook must make it easier to detect breaches and to verify compliance with the applicable rules. Digitisation does not lighten the owner's responsibility, then, so much as make it auditable, which is good news for anyone keeping their records properly and rather less so for everyone else.
BoatOn Book against the requirements of article 110.9.2
BoatOn Book is a marine CMMS that brings the logbook, the maintenance history, document management and crew records into a single environment, and several of the mechanisms described by article 110.9.2 belong to how it already works:
Time-stamped, non-destructive history, every job, event and check remaining attached to its equipment and its author, without an amendment replacing the original entry.
Dated checklists and controls — departure, arrival, planned maintenance, defects and safety checks — with a record of who signed off what and when.
Role-based rights, the master, the chief engineer, shore management and external contractors seeing neither the same screens nor the same permissions, each under their own credentials.
Documents and expiry dates, whether ship certificates, crew certificates and qualifications or inspection reports, with alerts ahead of expiry.
Export and archiving, through readable and printable outputs generated from the recorded data.
One point deserves to be stated plainly, however, because the commercial temptation would be to gloss over it: the approval referred to in article 110.9.2 covers a system installed aboard a named ship, and it is granted by the competent authority, not by the software vendor. No product, whatever its merits, is "compliant" in the abstract, and the declaration at annex 110-A.1 names a ship, an IMO number, a supplier, a version and an installation date. An owner intending to drop paper must therefore open that conversation for their own ship, with their own competent authority, and the outcome rests there.
What the regulations leave squarely with the owner, and where a tool genuinely changes the odds, is everything that happens before the inspection: knowing what was done on board, by whom and when, and being able to show it without reconstructing the record under pressure. That is the territory of preventive maintenance and traceability, and it is where the question of which system suits a given fleet is actually decided.
Three years, then, separated the commission's instruction from its appearance in the Official Journal. Fleets that used the interval to put their registers in order will treat the approval process as a formality, while the rest will discover that the difficulty was never the software, but the documentary discipline it assumes.
*Illustrative photographs — the bridge of a cargo ship, a trawler off Granville, crew working on deck. Credits: Pexels.*