Shared logins, slot resale and bots turn a booking portal into a weak point. A checklist for terminals and hauliers.
Why a booking portal is a cyber question
A truck appointment system lets trucking companies book a time slot to deliver or collect a container at a terminal. The portal is on the Internet, used by hundreds of people who do not work for the terminal, and every slot has a value. This page is for the terminal that runs the portal and for the trucking companies that use it. Every rule is tied to a public, dated source; the checklist below has 34 points.
Who is behind each booking
Points A1 to B5 of the checklist. Most of the rest depends on knowing who is behind each booking.
Each company runs its users
Recovery that cannot be talked around
Slot resale, brokering and bots
Points C1 to E3. The aim is not to stop automation: it is that every booking, by hand or by machine, goes through the same rules.
Every change recorded
Logs that prove who did what
Points F1 to F4. The joint guide of ASD's ACSC, CISA, the FBI, the NSA and their partners (21 August 2024) sets the baseline for event logging.
Hauliers see their own activity
What the trucking company protects on its side
Points G1 to G6, for the dispatch manager of each trucking company. They cost little and protect the company's own slots.
One login per dispatcher, MFA on
API keys in a vault
No broker holds your login
Report a strange booking
From the booking to the gate
Points H1 and H2. The cameras and OCR units that read plates and container numbers at the gate have their own page and checklist: gate camera and OCR security.
Eight areas, 34 points
Open the points below for what to check, why, the evidence to hold and the sources.
A · Accounts and roles · 5 points
B · Login and multi-factor authentication · 5 points
C · Slot integrity: resale and brokering · 5 points
D · Bots and rate limiting · 4 points
E · API access for transport management systems · 3 points
F · Access logs and detection · 4 points
G · The trucking company's side · 6 points
H · From the booking to the gate · 2 points
The 34 points and the evidence to hold
Click a point to read what to check, why, and the evidence to hold.
What to check
Every person who books, changes or cancels slots has a personal account: no login shared by a dispatch office, a shift or a group of drivers, and no account lent to a third party. The terms of use say so.
Why
A shared login cannot be traced to a person, cannot be removed when one person leaves, and cannot carry multi-factor authentication properly. The US Coast Guard rule asks for separate credentials and the removal of a user's credentials when the user leaves; NIS2 lists access control policies among the minimum measures.
Evidence to hold
- The terms of use of the portal with the one-person-one-account rule
- A list of accounts showing one named person per account (no generic names such as « dispatch » or « office »)
Sources: US Coast Guard, 33 CFR part 101 subpart F, Cybersecurity, § 101.650 (account security: lockout, MFA, least privilege, separate credentials, removal of leavers' credentials; protected logs; training), in force since 16 July 2025 (2025-01-17) · Directive (EU) 2022/2555 (NIS2), Article 21(2): supply chain security (d), access control (i), multi-factor authentication (j) (2022-12-14) · IMO, Guidelines on maritime cyber risk management, MSC-FAL.1/Circ.3/Rev.4 (3.5.3 protect: accounts and logs, 3.5.4 detect) (2026-05-28)
What to check
Each trucking company has one or two named administrators who create and remove the accounts of their dispatchers; the terminal knows who they are and can see the user list of each company.
Why
The terminal cannot know when a dispatcher leaves a trucking company. The company can, if it is given the tool and the responsibility. Without it, the accounts of people who left stay open.
Evidence to hold
- The named administrators of each trucking company, with the date of the last check
- The user list per company, readable by the terminal
Sources: US Coast Guard, 33 CFR part 101 subpart F, Cybersecurity, § 101.650 (account security: lockout, MFA, least privilege, separate credentials, removal of leavers' credentials; protected logs; training), in force since 16 July 2025 (2025-01-17) · Directive (EU) 2022/2555 (NIS2), Article 21(2): supply chain security (d), access control (i), multi-factor authentication (j) (2022-12-14)
What to check
At a written interval, each trucking company confirms its list of users; accounts not used for a period the terminal sets are disabled, and accounts of people who left are removed.
Why
Dormant accounts are a favourite target of credential stuffing because no one notices when they are used again. Removing the credentials of people who leave is a requirement of the US Coast Guard rule.
Evidence to hold
- The review procedure and the date of the last review
- The list of accounts disabled at the last review
Sources: US Coast Guard, 33 CFR part 101 subpart F, Cybersecurity, § 101.650 (account security: lockout, MFA, least privilege, separate credentials, removal of leavers' credentials; protected logs; training), in force since 16 July 2025 (2025-01-17) · OWASP Automated Threats to Web Applications, handbook v1.30 (OAT-005 Scalping incl. slot-booking bots, OAT-008 Credential Stuffing, OAT-021 Denial of Inventory) (2026-03-17)
What to check
Roles separate at least: booking for one's own company, administering one's own company's users, and terminal administration. Terminal administrator accounts are few, named and separate from the person's everyday account.
Why
The principle of least privilege for administrator accounts and separate credentials for critical systems are both in 33 CFR 101.650(a). An administrator account can change every booking on the terminal.
Evidence to hold
- The role matrix of the portal
- The list of terminal administrator accounts, with their owners
Sources: US Coast Guard, 33 CFR part 101 subpart F, Cybersecurity, § 101.650 (account security: lockout, MFA, least privilege, separate credentials, removal of leavers' credentials; protected logs; training), in force since 16 July 2025 (2025-01-17) · IMO, Guidelines on maritime cyber risk management, MSC-FAL.1/Circ.3/Rev.4 (3.5.3 protect: accounts and logs, 3.5.4 detect) (2026-05-28)
What to check
A transport management system or a script that books slots uses an API key issued for that integration, never the username and password of a dispatcher.
Why
A person's password stored in a script is a shared account by another name: it does not leave with the person and cannot do multi-factor authentication. It also pushes integrators to automate the web pages instead of the API.
Evidence to hold
- The list of API keys, one line per integration and per trucking company
- The rule, in the terms of use, that automation goes through the API
Sources: OWASP API Security Top 10, 2023 edition (API1 broken object level authorization, API2 broken authentication, API4 unrestricted resource consumption, API6 unrestricted access to sensitive business flows) (2023-06-05) · US Coast Guard, 33 CFR part 101 subpart F, Cybersecurity, § 101.650 (account security: lockout, MFA, least privilege, separate credentials, removal of leavers' credentials; protected logs; training), in force since 16 July 2025 (2025-01-17)
What to check
Every account that can book, change or cancel a slot logs in with a second factor (an authenticator app, a security key or a passkey); SMS is a temporary fallback only, written as such.
Why
A password alone is reused, phished or guessed. NIS2 lists multi-factor authentication among the minimum measures (Article 21(2)(j)); 33 CFR 101.650(a)(4) requires it on password-protected IT systems. CISA describes SMS and voice codes as weaker than the alternatives.
Evidence to hold
- The portal setting that enforces MFA, with the share of active accounts enrolled
- The list of accounts still without MFA, each with a reason and a date
Sources: Directive (EU) 2022/2555 (NIS2), Article 21(2): supply chain security (d), access control (i), multi-factor authentication (j) (2022-12-14) · US Coast Guard, 33 CFR part 101 subpart F, Cybersecurity, § 101.650 (account security: lockout, MFA, least privilege, separate credentials, removal of leavers' credentials; protected logs; training), in force since 16 July 2025 (2025-01-17) · CISA, Implementing Phishing-Resistant MFA (fact sheet) (2022-10-31)
What to check
Terminal administrators, and if possible trucking-company administrators, use phishing-resistant authentication (security keys or passkeys based on FIDO2/WebAuthn, or certificates).
Why
An administrator account controls every slot. CISA's fact sheet of October 2022 says FIDO/WebAuthn and PKI-based authentication are the phishing-resistant options and asks organisations to start with their most exposed accounts.
Evidence to hold
- The authentication method of each administrator account
Sources: CISA, Implementing Phishing-Resistant MFA (fact sheet) (2022-10-31) · NIST, SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (2025-07-31)
What to check
Repeated failed logins on one account lead to a delay or a lockout; many failed logins across accounts from the same addresses are blocked and raise an alert.
Why
Credential stuffing tries passwords leaked elsewhere on many accounts at once. 33 CFR 101.650(a)(1) requires automatic lockout after repeated failures; NIST SP 800-63B-4 asks verifiers to limit failed attempts; OWASP lists credential stuffing and the lack of such limits as a broken-authentication risk (API2:2023).
Evidence to hold
- The lockout and throttling settings of the portal and of the API
- An example alert from a test
Sources: US Coast Guard, 33 CFR part 101 subpart F, Cybersecurity, § 101.650 (account security: lockout, MFA, least privilege, separate credentials, removal of leavers' credentials; protected logs; training), in force since 16 July 2025 (2025-01-17) · NIST, SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (2025-07-31) · OWASP API Security Top 10, 2023 edition (API1 broken object level authorization, API2 broken authentication, API4 unrestricted resource consumption, API6 unrestricted access to sensitive business flows) (2023-06-05) · OWASP Automated Threats to Web Applications, handbook v1.30 (OAT-005 Scalping incl. slot-booking bots, OAT-008 Credential Stuffing, OAT-021 Denial of Inventory) (2026-03-17)
What to check
When a user sets a password, it is checked against a list of passwords known to be compromised or too common, and refused if it matches.
Why
NIST SP 800-63B-4 asks verifiers to compare new passwords against such a blocklist. It stops the passwords that credential stuffing tries first.
Evidence to hold
- The password policy of the portal, with the blocklist check
What to check
A forgotten password or a lost second factor is reset through a written process that checks the person (for example through the trucking company's own administrator), never on a phone call to the help desk alone. The user is told by e-mail when the password, the second factor or the e-mail address changes.
Why
The help desk that resets accounts on request is the shortest way around multi-factor authentication. This point is plain practice; the US Coast Guard rule asks personnel to be trained on the techniques used to circumvent security measures.
Evidence to hold
- The written reset procedure for the help desk
- The notification e-mail sent on a change of password, factor or address
What to check
The terms of use say whether a slot can be passed from one trucking company to another, and if so only through the portal, with both companies named; selling slots, or booking slots to sell them on, is forbidden.
Why
When slots are scarce, some accounts book them to resell them, by hand or with bots: OWASP names this threat scalping (OAT-005) and lists the slot-booking bot among its forms. A rule that is not written cannot be enforced.
Evidence to hold
- The clause of the terms of use on transfers and resale
- The date the trucking companies accepted the current version
Sources: OWASP Automated Threats to Web Applications, handbook v1.30 (OAT-005 Scalping incl. slot-booking bots, OAT-008 Credential Stuffing, OAT-021 Denial of Inventory) (2026-03-17) · OWASP API Security Top 10, 2023 edition (API1 broken object level authorization, API2 broken authentication, API4 unrestricted resource consumption, API6 unrestricted access to sensitive business flows) (2023-06-05)
What to check
Each booking holds the trucking company, the container or cargo reference and, before the arrival, the truck registration; a booking without a company is refused.
Why
A slot that does not say who will use it can be sold to anyone. Naming the company and the truck lets the gate check the booking (section H) and makes resale visible in the records.
Evidence to hold
- The mandatory fields of a booking, read in the portal
What to check
A change of company, truck, driver, container or time on a booking is recorded with who made it, from which account or API key, and when; the history is kept with the booking.
Why
Brokered slots show up as bookings that change hands or trucks shortly before the slot. Without the history, the terminal cannot tell a normal change from a sale.
Evidence to hold
- The change history of a sample booking
Sources: ASD's ACSC, CISA, FBI, NSA and partners, Best Practices for Event Logging and Threat Detection (2024-08-21) · US Coast Guard, 33 CFR part 101 subpart F, Cybersecurity, § 101.650 (account security: lockout, MFA, least privilege, separate credentials, removal of leavers' credentials; protected logs; training), in force since 16 July 2025 (2025-01-17)
What to check
The terminal looks for slots cancelled by one account and taken by another account within moments, for accounts that book far more slots than they use, and for accounts that always book the instant slots are released.
Why
These are the traces of slot brokering and of hoarding. OWASP describes hoarding without using as denial of inventory (OAT-021) and fast automated buying as scalping (OAT-005). This point is detection, not a verdict: the terminal checks before it acts.
Evidence to hold
- The report or query used, with its date and owner
- The last review of its results
Sources: OWASP Automated Threats to Web Applications, handbook v1.30 (OAT-005 Scalping incl. slot-booking bots, OAT-008 Credential Stuffing, OAT-021 Denial of Inventory) (2026-03-17) · OWASP API Security Top 10, 2023 edition (API1 broken object level authorization, API2 broken authentication, API4 unrestricted resource consumption, API6 unrestricted access to sensitive business flows) (2023-06-05)
What to check
The terms of use say what happens to repeated no-shows and late cancellations, and the rule is applied the same way to every trucking company.
Why
If holding a slot costs nothing, booking slots in case, or to resell, is rational. A written, equal rule removes the incentive. This point is plain practice; the rule itself is the terminal's business decision.
Evidence to hold
- The clause on no-shows and late cancellations
- The record of its application
What to check
The terminal has listed the flows that would hurt if used too fast or too often: login, slot search, booking, change, cancellation, and account creation.
Why
OWASP's API6:2023 (unrestricted access to sensitive business flows) gives the example of an attacker who reserves all the available time slots and prevents other users from using the system, and asks to identify these flows first, then to choose protections.
Evidence to hold
- The list of sensitive flows, with the protection chosen for each
What to check
Each sensitive flow has a limit per account, per API key and per network address, set from the real use of the portal, with a clear error when a limit is reached.
Why
OWASP API4:2023 (unrestricted resource consumption) and API6:2023 both ask for limits. Without them, one script can search and book faster than every dispatcher together.
Evidence to hold
- The rate-limit settings, flow by flow
- A test showing the limit and the error
What to check
The portal or its protection layer looks at how the booking flow is used (headless browsers, request timing, the same sequence repeated without pause) and can challenge or block it.
Why
OWASP lists device fingerprinting, human detection and the analysis of non-human patterns among the ways to slow automated abuse of a business flow (API6:2023).
Evidence to hold
- The detection in place and where its alerts go
Sources: OWASP API Security Top 10, 2023 edition (API1 broken object level authorization, API2 broken authentication, API4 unrestricted resource consumption, API6 unrestricted access to sensitive business flows) (2023-06-05) · OWASP Automated Threats to Web Applications, handbook v1.30 (OAT-005 Scalping incl. slot-booking bots, OAT-008 Credential Stuffing, OAT-021 Denial of Inventory) (2026-03-17)
What to check
The way and the time new slots are released are documented, and every trucking company sees them the same way, through the portal or the API.
Why
When release is predictable to some and not to others, bots and brokers gain the advantage that a slot-booking bot is built for. This point is plain practice.
Evidence to hold
- The published release rule
What to check
Trucking companies that want to automate get a documented API for slot search and booking, with the same rules as the portal; scraping the web pages is not needed and is forbidden by the terms of use.
Why
If no API exists, integrators automate the web pages with stored logins, which looks exactly like a bot. OWASP asks to secure and limit access to APIs consumed directly by machines (API6:2023).
Evidence to hold
- The API documentation and its access conditions
What to check
Each API key belongs to one trucking company and one integration, can only act for that company, can be revoked at once, and is replaced when a person who handled it leaves or when it may have been exposed.
Why
A key shared between companies or integrations cannot be traced or revoked without breaking everyone. NIS2 lists the security of the relationships with suppliers and service providers among the minimum measures.
Evidence to hold
- The key register (company, integration, scope, creation date, last use)
- The revocation procedure
Sources: OWASP API Security Top 10, 2023 edition (API1 broken object level authorization, API2 broken authentication, API4 unrestricted resource consumption, API6 unrestricted access to sensitive business flows) (2023-06-05) · Directive (EU) 2022/2555 (NIS2), Article 21(2): supply chain security (d), access control (i), multi-factor authentication (j) (2022-12-14)
What to check
Every API call that reads or changes a booking checks that the key belongs to the company that owns the booking; a key cannot read or cancel another company's bookings by changing an identifier.
Why
Broken object-level authorisation is the first risk of the OWASP API Security Top 10 (API1:2023). On a booking API it means one trucking company can see or cancel another's slots.
Evidence to hold
- A test where a key tries to read and cancel another company's booking and is refused
What to check
The portal and the API log: logins (successful and failed), MFA and password changes, account creation and removal, bookings, changes, cancellations, transfers, administrator actions, and API calls with the key that made them.
Why
Without these events, none of the checks of sections A to E can be proven or investigated. The joint guide on event logging (ASD's ACSC with CISA, the FBI, the NSA and partners, 21 August 2024) sets a baseline for what to log and how.
Evidence to hold
- The list of logged events
- A sample log entry for a booking change
Sources: ASD's ACSC, CISA, FBI, NSA and partners, Best Practices for Event Logging and Threat Detection (2024-08-21) · IMO, Guidelines on maritime cyber risk management, MSC-FAL.1/Circ.3/Rev.4 (3.5.3 protect: accounts and logs, 3.5.4 detect) (2026-05-28)
What to check
Logs are sent to a place that portal administrators and the vendor cannot edit, and kept for a period written in the security plan.
Why
33 CFR 101.650(c)(1) requires logs to be securely captured, stored and protected so that only privileged users can reach them. A log that the person it records can delete proves nothing.
Evidence to hold
- Where the logs go and who can read or delete them
- The written retention period
Sources: US Coast Guard, 33 CFR part 101 subpart F, Cybersecurity, § 101.650 (account security: lockout, MFA, least privilege, separate credentials, removal of leavers' credentials; protected logs; training), in force since 16 July 2025 (2025-01-17) · ASD's ACSC, CISA, FBI, NSA and partners, Best Practices for Event Logging and Threat Detection (2024-08-21)
What to check
Alerts exist at least for: many failed logins, a login from an unusual place for an administrator, MFA removed from an account, an account or API key booking far above its usual pattern, and administrator changes to bookings. Each alert has an owner.
Why
Logs nobody reads detect nothing. IMO Rev.4 asks to detect cyber events (3.5.4); the joint logging guide asks for detection based on the events collected.
Evidence to hold
- The alert list with an owner for each
- The last alert handled, with what was done
Sources: IMO, Guidelines on maritime cyber risk management, MSC-FAL.1/Circ.3/Rev.4 (3.5.3 protect: accounts and logs, 3.5.4 detect) (2026-05-28) · ASD's ACSC, CISA, FBI, NSA and partners, Best Practices for Event Logging and Threat Detection (2024-08-21)
What to check
A trucking company's administrator can see the logins and booking actions of the company's own accounts and API keys.
Why
The trucking company is the first to notice a login or a booking that none of its dispatchers made, if it can see them. This point is plain practice.
Evidence to hold
- The activity view offered to trucking-company administrators
What to check
Each dispatcher has a personal account with multi-factor authentication turned on; no login is written on a board, in a shared document or in a group chat.
Why
Bookings made from a shared login are bookings no one can account for. If the terminal offers MFA, the trucking company turning it on is the cheapest protection of its slots.
Evidence to hold
- The list of the company's portal users, one per person, MFA on
Sources: CISA, Implementing Phishing-Resistant MFA (fact sheet) (2022-10-31) · Directive (EU) 2022/2555 (NIS2), Article 21(2): supply chain security (d), access control (i), multi-factor authentication (j) (2022-12-14)
What to check
When a dispatcher, driver with an account or subcontractor stops working for the company, the company's portal administrator removes the account and any API key the person handled is replaced.
Why
A former employee's account can still book and cancel the company's slots. The US Coast Guard rule asks for the removal of credentials when a user leaves; the same logic applies on the trucking company's side.
Evidence to hold
- The leaver checklist with the portal on it
What to check
The API key of the transport management system is stored in the TMS's secret store or a password manager, never in an e-mail, a spreadsheet or the source code, and only the people who need it can read it.
Why
An API key sent by e-mail or kept in a file is a password anyone who finds it can use. This point is plain practice; NIS2 lists access control and cryptography policies among the minimum measures.
Evidence to hold
- Where the key is stored and who can read it
What to check
The company books only through its own accounts and does not buy slots from, or give its login to, an intermediary offering « guaranteed » slots.
Why
A broker who holds your login can book, cancel and read in your name; slots bought from a third party may break the terminal's terms of use and may be cancelled. This point is plain practice.
Evidence to hold
- The rule written in the company's dispatch instructions
What to check
Dispatchers know the portal's real address, type it or use a bookmark, and know the terminal never asks for a password or an MFA code by e-mail, phone or message. A suspicious message is reported to the terminal.
Why
A copy of the login page collects the password and the one-time code together; only phishing-resistant methods stop it (CISA, October 2022). The US Coast Guard rule includes recognising threats in the training of personnel.
Evidence to hold
- The short instruction given to dispatchers
- The terminal's contact for reporting
Sources: CISA, Implementing Phishing-Resistant MFA (fact sheet) (2022-10-31) · US Coast Guard, 33 CFR part 101 subpart F, Cybersecurity, § 101.650 (account security: lockout, MFA, least privilege, separate credentials, removal of leavers' credentials; protected logs; training), in force since 16 July 2025 (2025-01-17)
What to check
The company checks its upcoming bookings, and tells the terminal at once about a booking, cancellation or login it did not make.
Why
The terminal sees many companies; each company knows its own trucks. The two views together catch account takeover early. This point is plain practice.
Evidence to hold
- Who checks the bookings, and how often
- The terminal's contact for reporting
What to check
At the gate, the truck registration and the container are checked against the booking (by a clerk or by gate cameras and OCR); a mismatch goes to a person, and the decision is recorded.
Why
If the gate only checks that a slot exists, a resold or stolen slot works as well as a real one. The gate camera and OCR page of Port Cyber Alliance covers the devices that make this check.
Evidence to hold
- The gate procedure for a booking that does not match the truck
- The record of mismatches over a recent period
What to check
The portal asks only for the driver and truck data the terminal needs, says why and for how long it is kept, and deletes it at the end of a written period.
Why
Driver names, licence numbers and plates are personal data in the EU: collect what the purpose needs, keep it no longer than needed, secure it, tell the people (GDPR Articles 5, 13 and 32). Outside the EU, check the law of each jurisdiction. This is not legal advice.
Evidence to hold
- The list of driver data fields and the purpose of each
- The retention period and the privacy notice
Sources: Regulation (EU) 2016/679, General Data Protection Regulation (Articles 5, 13 and 32) (2016-04-27)
Download the checklist
One checklist, two formats. Version 1.0, published 11 November 2026. Generic: no terminal, port, client or portal vendor named, no invented figure.
Truck appointment portals: questions
Click a question to read the answer.
Because a slot is something of value that changes hands on the Internet. Whoever controls an account can book, change or cancel a trucking company's slots, and a script can book faster than every dispatcher together. OWASP's API Security Top 10 (5 June 2023) gives exactly this example: an attacker who reserves all the available time slots and prevents other users from using the system.
In the EU, NIS2 lists multi-factor authentication among the minimum measures of the entities in its scope (Article 21(2)(j)). In the United States, 33 CFR 101.650(a)(4), in force since 16 July 2025, requires it on password-protected IT systems of regulated facilities, with documented compensating controls where it is not feasible. Whether your portal is in scope depends on who runs it: check with your security officer. This is not legal advice.
Not from one booking, but from patterns in the records: slots cancelled by one account and taken by another within moments, accounts that book far more than they use, bookings whose company or truck changes shortly before the slot, accounts that always book the instant slots are released. These are signals to check, not proof: the terminal looks before it acts, and the rule it applies must be written in its terms of use.
Its logins (one per dispatcher, with MFA), its leavers (accounts removed the same day), its API keys (in a vault, not in an e-mail or a spreadsheet), and its slots (no login given to a broker, no slot bought from a third party). It should also check its upcoming bookings and tell the terminal at once about one it did not make.
Yes. The CSV and PDF are published under the Creative Commons Attribution 4.0 licence (CC BY 4.0): copy and adapt them, including commercially, as long as you credit Port Cyber Alliance and link to this page. The checklist is generic, names no terminal or portal vendor, and is not legal advice.
Related pages
Twelve questions, about two minutes, for the engineer who runs the portal, accounts and network: it runs in the browser and sends nothing.
Test your portal engineer