Security posture
The fraud this network defends against runs on stolen identity and public information. The security design answers it wall by wall.
This is a working draft, prepared for counsel review. The executed membership agreement governs.
Mandatory two-factor. Authenticator-app TOTP on every account, no opt-out. SMS is not the second factor — SIM-swap is a documented attack in exactly this fraud class — and serves only as an emergency fallback, if at all.
Re-authentication. Sensitive actions — changing insurance details, adding a driver or a truck, accepting a movement — require a fresh authenticator code, and each is logged.
Session discipline. Short session lifetimes with idle timeout; administrative sessions shorter still. Email notice on every new-device sign-in, password change and MFA reset.
Row-level enforcement. Row Level Security on every table holding member, load or document data. The assumption is a determined attacker calling the API directly, not a well-behaved browser.
Protected details are split. Board-visible load data and protected details — addresses, VIN, declared value, owner contact, access notes — live in separate tables. The protected table is readable only by the posting broker, the assigned carrier and administrative oversight. Structural, not cosmetic.
Least-privilege administration. Reviewing an application is not the same permission as removing a member. Administrative roles carry only the authority their function requires.
An audit log that cannot be silently edited. Sign-ins, document views, tier changes, assignments, protected-detail releases and administrative decisions are all recorded.
Rate limits and anomaly alerting. Sign-in, application and board queries are rate-limited. Alerts fire on unusual query volume, repeated failed sign-ins, a driver added immediately before a high-value pickup, or acceptances exceeding a carrier's registered equipment.
This posture does not promise that nothing can go wrong, and nobody here will promise that. The design goal is a materially harder target than an open board, fast detection when something is wrong, and a permanent record of every consequential action.
Verified, not guaranteed.
Found a security flaw? Report it to security@echelontransportnetwork.com. A vulnerability report needs its own address, published where a researcher will look for it, or it arrives at a public inbox or not at all. That address is monitored and filtered separately.
Reports are acknowledged, and researchers acting in good faith are not pursued.
Questions about this document belong with the verification desk through your member contact, or with counsel during the review period. In writing: verification@echelontransportnetwork.com.