Access control policy

One rule runs through this policy: LFW never asks for or stores a client’s passwords. It takes delegated access, in its own name, limited to what the work needs, and revocable by the client at any time.

Version 1.0, October 6, 2026. Part of the published practices on the trust page. The information security policy covers the systems these accounts live in.

1. Accounts in the client’s name

Hosting, the domain, the code repository and the administrator accounts on a client’s site are in the client’s name from the first day. LFW is a user in the client’s accounts, never the owner of them.

The client can see exactly what LFW can reach, and can remove it without asking. When a retainer ends, LFW returns credentials, account access and repository access at no charge.

2. How LFW gets access to a client system

For each system the work needs, LFW asks the client to grant a named account to LFW’s own address using the provider’s own delegation feature: a member on the hosting account, a company user on the host’s dashboard, a member with a scoped role on the Cloudflare account, an administrator user in WordPress.

LFW accepts each invitation and turns on multifactor authentication on that account where the platform offers it. Where a provider has no delegation, LFW asks for a dedicated login created for it, never the owner’s personal login.

The few credentials LFW must hold are kept in a password manager, in a vault for that client alone. A client sends such a credential through a one-time secure link, not in email.

LFW asks only for what the engagement needs. Registrar access is usually not needed at all: the preferred setup is DNS delegated to a Cloudflare zone, which leaves the registrar untouched.

3. Signing in to LFW’s systems

The Client Portal has no passwords. A client signs in with an emailed link that works once and expires after 15 minutes, with a passkey, or through the client’s own identity provider over OpenID Connect.

Requests for sign-in links are rate limited per address and per email, and the response is the same whether or not the address has an account, so the form cannot be used to list clients. A session lasts 14 days in a cookie the browser keeps host-only, secure and out of reach of scripts.

LFW’s staff sign in to the staff site the same way, on a separate origin. There is no password anywhere in LFW’s systems to steal or reuse.

4. Roles in the Client Portal

Portal access is granted deliberately, per person, by LFW. Being a contact on file, or being at a client organization, does not grant it. Revoking access invalidates every session that person holds, and a later grant does not revive them.

Client roles are owner, member and viewer. Owners see every site in their organization; a member sees the sites they are granted and nothing else, not another site in their own organization and not another organization. Document history is append-only, so a restore adds a revision rather than erasing one.

When LFW staff view a client’s portal to help with a request, the view is read-only, labeled on screen, logged, and reached through a single-use token that expires in two minutes.

5. Access to the server

The server accepts SSH by key only. The application and every scheduled job run as an unprivileged service account with no login shell, and the data directory is readable by that account alone. The secrets file is readable by root and that account only.

Builds never touch the server’s keys: they run in a disposable container with no mounts, which receives the source over its input and returns the built site over its output.

6. Review and revocation

LFW keeps an inventory, per client, of every account it holds and how to revoke it. The inventory is the offboarding list: when the retainer ends, every entry is returned or removed, and the client confirms.

A client may remove LFW’s access at any time without notice. LFW does not treat that as a breach of the agreement, and it does not change what the client owns.

7. Subcontractors

LFW has no employees and uses no subcontractor on a client’s site without the client’s written approval. Anyone LFW ever brings in is bound to the same confidentiality terms and gets the same kind of named, limited, revocable access.

8. What this policy does not claim

LFW does not participate in InCommon or another trust federation. It does not offer a client-facing report of each user’s sign-ins and sign-outs yet; what the portal records is in the information security policy.