Discretion is not
a feature. It is the standard.

Our approach

Everything on this page exists to answer one question honestly: if you told LX something in confidence, who could ever see it, and how is it technically prevented from leaking anywhere else? Where we can describe the exact mechanism — a hashing algorithm, a cookie flag, a rate limit — we do, rather than speaking in generalities.

How membership is approved

Creating an account and signing in confirms your identity; it does not automatically make you an LX member. Every membership grant is reviewed and approved individually by our private office — a person, not an automated rule — before member access is switched on for that account. Until approval, a signed-in account sits in a pending state and cannot see member-only content.

Your data stays yours

The member area is built, page by page, to load only the signed-in member’s own journeys, requests and profile. Every query behind the member dashboard is scoped to that member’s own identifier before it runs — there is no view, in the member area or otherwise, that shows one member’s information to another, and no shared or aggregate dashboard that a member can browse across other members’ records.

How your account is protected

Sign-in is handled entirely by our own first-party systems — there is no external identity provider in the loop, and no third party that sees your credentials.

Passwords

Your password is never stored, by us or anyone else, in a form that could be read back. When you set or change it, it is run through PBKDF2-HMAC-SHA256 with 210,000 iterations and a unique, randomly generated salt for your account alone, and only the resulting cryptographic hash is written to our database. Signing in re-runs the same computation on what you type and compares the two hashes in constant time — your original password is never retained anywhere along the way, and even a full copy of our database would not reveal it.

Access keys

Where an access key is issued to you as an alternative way to sign in, it is generated at random and shown to you once, at the moment of issuance. From that point on, only a SHA-256 hash of the key is stored — the key itself cannot be derived from that hash, so losing the original key means it must be reissued, not recovered.

Sessions

Once you sign in, your browser is given a session cookie containing a random 32-byte token. That cookie is marked HttpOnly (unreadable to any script running on the page, so it cannot be exfiltrated by a malicious script), Secure (only ever sent over an encrypted HTTPS connection) and SameSite=Lax (not attached to requests initiated from other sites, which limits cross-site request forgery). On our side, we store only a hash of that token, never the token itself. A session expires automatically after 30 days, and signing out deletes it from our server immediately — not just from your browser.

What we ask, and don’t ask, for

For an initial conversation we only require your name, email and phone number — destination, dates, party size and notes are optional until an advisor is actually arranging something for you. We do not ask for payment details, passport numbers or travel documents through this website; when those are genuinely needed, your advisor will arrange to collect them directly and securely, away from this site.

Protecting the request forms

Our request, appointment and sign-in forms are protected by two independent, automated measures:

• Rate limiting — no more than five submissions from the same IP address, to the same form, are accepted within any rolling ten-minute window. The address behind this check is passed through a one-way hash before it is ever compared or stored, so the raw address itself is not retained.
• A hidden honeypot field — a form field that is invisible to a person filling in the form normally, but visible to most automated bots. A submission that fills it in is silently discarded as automated, with no error shown, so the bot cannot tell it was blocked.

Sensitive fields — full names, phone numbers, travel dates, passport information and free-text notes — are never written to general application logs; only a minimal, anonymised record of significant events (such as “a request was received”) is kept, identifying no one.

Access and connections

Every connection to this platform is encrypted using industry standard HTTPS/TLS; there is no unencrypted path for a request, sign-in or member page to travel. Access to request details and account records is limited to private office staff who need it to respond to you, and no plaintext password is ever visible to anyone, including our own staff — the storage mechanism described above makes that structurally true, not just a policy.

Working with outside providers

When a request moves from an enquiry into an actual arrangement, we share only the details a specific third-party provider — an aircraft operator, a residence owner, a protection team and so on — genuinely needs to deliver it, and only once you have confirmed you want to proceed. We work with providers on a need-to-know basis and expect the same discretion from them that we hold ourselves to; see our Terms for how those relationships are structured.

If something looks wrong

If you ever see anything in the member area that does not belong to you, or notice anything else that concerns you, please tell us straight away via Request Introduction so our private office can look into it.

Related reading

For how we collect, use and retain your information more broadly, see our Privacy Notice. For how membership, requests and third-party arrangements work, see our Terms. For how a request actually moves once you send it, see How We Work.