Unique to one individual: what AC 120-78B demands and what MRO systems deliver
Aviation has the strictest signature doctrine of any industry. 14 CFR §43.9 demands the name, signature, certificate number and certificate type of the person approving an aircraft for return to service. §43.12 makes falsifying that record a certificate action. The doctrine is superb. The implementation is a password.
What does 'unique to one individual' actually require?
That the signature cannot be produced by anyone else, and that the individual has sole control of whatever produces it. FAA advisory material states it plainly. In production it is frequently a login to a maintenance system, sometimes on a shared shop terminal, which fails both halves.
- Uniqueness and sole control are properties of a credential, not of an account policy. A password satisfies neither once it can be typed by a second person.
- The FAA consolidated and expanded its falsification provisions by final rule in February 2026, raising the consequence attached to every maintenance record.
- Seven properties, applied to four common signature architectures, produce a score you can take to your quality board.
Part of Aviation and airworthiness identity
The regulation, precisely
14 CFR §43.9(a)(4) requires the maintenance record entry to include the signature, certificate number and kind of certificate held by the person approving the work. §43.11 imposes parallel requirements for inspections. §43.12 prohibits any fraudulent or intentionally false entry, and makes such an entry a basis for suspending or revoking the certificate of the person who made it.
Advisory Circular 120-78B addresses acceptance of electronic signatures, recordkeeping and manuals. Its operative characteristics for a signature are that it must be unique to one individual, under the sole control of that individual, capable of verification, and linked to the record such that a subsequent change is detectable.
Read those four characteristics as an engineer rather than as a compliance reader. They are a specification, and they describe a possession-based credential with content binding. They do not describe a username and a password.
What sole control means when there is a shop terminal
Sole control is the property that a knowledge factor cannot have. A password is a string; a string can be observed, remembered, written down, or typed by a lead technician closing out a work package for someone who went home at shift change.
None of that is exotic misconduct. It is the ordinary operation of a hangar, and it is why MRO quality systems spend effort on individual-account policies, badge readers and periodic disciplinary reminders — procedural controls against a property the technology does not provide.
The seven-property test
Score each of your systems. Yes or no; partial credit hides the problem.
| # | Property | Derived from |
|---|---|---|
| 1 | Is the signing factor something the individual possesses, not something they know? | AC 120-78B sole control |
| 2 | Can the factor be used by another person without the individual's physical participation? | AC 120-78B uniqueness |
| 3 | Does the signature cover the record content, such that alteration breaks verification? | AC 120-78B linkage |
| 4 | Does the record include certificate number and kind of certificate within the signed object? | §43.9(a)(4) |
| 5 | Can a third party verify the signature without access to your maintenance system? | AC 120-78B verifiability |
| 6 | Is a correction distinguishable from an alteration in the verified record? | §43.12 exposure |
| 7 | Does verification survive the software vendor ceasing to exist? | Record retention horizon |
Four architectures, scored
| Architecture | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|---|---|---|---|---|---|---|---|
| Username and password in the MIS | No | No | No | Partly | No | No | No |
| Password plus badge swipe at terminal | Partly | No | No | Partly | No | No | No |
| PKI smartcard signing the record | Yes | Yes | Yes | Yes | Partly | Partly | Partly |
| Hardware credential with user verification, signing a canonical record statement | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Property seven deserves a note. Aircraft records outlive software vendors routinely — a 1998 airframe has changed maintenance systems three times. A signature that can only be verified inside a specific product is a signature with an expiry date that nobody wrote down.
The canonical maintenance record statement
What gets signed should be what §43.9 says the record must contain, rendered as the technician saw it.
{
"type": "manav-stmt/1",
"action": "approve_for_return_to_service",
"render": [
"Aircraft: [registration] — [type] — S/N [serial]",
"Work performed: [description of work]",
"Reference: [maintenance data, revision]",
"Total time in service: [hours]",
"Date: [date of completion]",
"Approved by: [name], cert [number], [kind of certificate]"
]
}Canonicalisation under RFC 8785 means the same logical content always yields identical bytes, which is what makes property three — alteration detection — actually work across systems rather than only within one.
Who this protects
It is tempting to frame this as an organisational risk control. It is more accurately a technician protection.
Under §43.12, the exposure for a false entry attaches to the individual whose certificate is on the record. A mechanic disputing an entry made under their credentials currently has nothing to offer but their word against a system log. A signature they did not produce is exculpatory evidence, and today it does not exist — which is an argument worth making to a union as readily as to a quality board.
What the FAA has and has not said
The agency accepts electronic signatures meeting the AC's characteristics, and password-based implementations are in widespread accepted use. Nothing here asserts that any MRO is non-compliant or that any system has been rejected.
The claim is narrower and testable: acceptance and evidentiary strength are different properties, and the seven-property test measures the second one.
A seven-property conformance test
| Property | Evidence required |
|---|---|
| Unique to one individual | No shared or generic accounts on signing terminals |
| Sole control | Something the individual holds, not something they can tell someone |
| Not readily forgeable | Key material in hardware, not a hash in a table |
| Bound to the specific record | A digest of the record inside the signature |
| Detects later alteration | Verification fails if the record changed |
| Retained with the record | For the required retention period |
| Verifiable by a third party | Without access to the operator's systems |
Objections and honest limits
“Our system requires a password re-entry to sign.” That tests knowledge, which is shareable, and it is frequently shared on a shop floor for entirely practical reasons. Sole control means possession, not knowledge.
“Regulators accept our system today.” Acceptance reflects what has been available. The conformance question is what the signature proves, and that is the question asked after an incident rather than during an audit.
Running the test on your own system
- Inventory signing terminals. And whether any of them carry shared or generic accounts.
- Establish what produces the signature. Knowledge, possession, or both.
- Check binding. Does the signature cover the record's contents, or only reference it?
- Check third-party verifiability. Could a regulator check it without your systems, in ten years?
Terms used here
- Sole control
- The property that only the named individual can cause the signature to be produced. Knowledge-based factors fail this because knowledge is shareable.
- Conformance test
- A checklist converting advisory language into properties a system either has or does not.
- Record binding
- Including a digest of the signed record inside the signature, so alteration is detectable.
Frequently asked questions
Is a password-based RTS signature non-compliant? No. Password-based electronic signatures are in accepted use across the industry. The test measures evidentiary strength, not regulatory acceptance, and the article is explicit about the distinction.
Would this require re-validating our maintenance system? The change is at the signing component. The record structure, the data fields and the audit trail are unchanged, so in most architectures this is a change control rather than a revalidation.
How does this interact with EASA Part-145 requirements? The uniqueness and sole-control concepts appear in comparable form. A signature that satisfies the seven properties satisfies both frameworks' characteristics; acceptance remains a matter for each authority.
What about paper records? A wet signature has sole control by default. The test is aimed at electronic records, where that property has to be engineered rather than assumed.
Does a password re-entry satisfy sole control? No. Knowledge is shareable and is frequently shared on a shop floor. Sole control means possession of something only that individual holds.
What is the most commonly failed property? Binding. Most systems record that a person signed, not what they signed, so a later alteration is undetectable.
Why does third-party verifiability matter? Because the record must outlive the maintenance system, and a regulator should not need your systems to check it.
Where this fits in Manav
Manav binds an airworthiness or operational signature to the exact record it certifies, on a credential under one individual's sole control, and produces a receipt an auditor or a regulator can verify years later without access to the operator's systems.
Sources and further reading
- 14 CFR §§43.9, 43.11 and 43.12 — maintenance record content, inspection entries and falsification.
- FAA Advisory Circulars
- Federal Aviation Administration regulations and policies
- RFC 8785 — JSON Canonicalization Scheme