Password Policy

1. Purpose

This policy sets the standards for passwords, multi-factor authentication, and the handling of authentication secrets at Lever AI. It is informed by NIST SP 800-63B and supports the Access Control Policy, which governs who is granted access; this policy governs the credentials through which that access is exercised.

2. Scope

This policy applies to all Lever AI personnel and to any contractor or third party acting on the company's behalf. It covers every account used for company business — cloud, source-control, data-store, and work-tool accounts, and the accounts on work devices — and every service credential the company holds, including the customer-provisioned tenant credentials kept in the restricted auth store.

3. Policy

3.1 Password standards

Passwords are at least 12 characters long; passwords for administrative accounts are at least 14. A randomly generated password or passphrase from the password manager satisfies this policy and is the preferred way to meet it — length and unpredictability matter more than composition rules. Every password is unique to its system: no password is reused across systems, and no personal password is used for work. Default or vendor-supplied passwords are changed before a system is used.

3.2 Password manager

A password manager is used for all work credentials. Passwords are generated by it rather than invented, and are retrieved from it rather than remembered or retyped from elsewhere. The manager's own master credential meets the administrative standard above, is used nowhere else, and is protected with multi-factor authentication where the manager supports it.

3.3 Rotation

There is no forced periodic password rotation. A password is changed without delay when its compromise is suspected or confirmed; when a break-glass credential has been used; when a device that could hold it is lost or stolen (reportable within 24 hours under the Physical Security Policy); and when someone with knowledge of one of the few shared secrets permitted by section 3.5 leaves the company.

3.4 Multi-factor authentication

Multi-factor authentication is required on all production, cloud, and source-control accounts, without exception other than as granted under section 5. It is enabled on every other work account where the system supports it. Phishing-resistant factors are preferred where available; SMS is used only where nothing stronger is offered.

3.5 Shared accounts

Shared accounts are prohibited. The single exception is break-glass credentials: emergency credentials stored sealed — held so that any use is an overt act, such as a sealed entry in the password manager reserved for emergencies — whose every use is logged and reported, and which are rotated after each use, as governed by section 3.7 of the Access Control Policy.

3.6 Service credentials and secrets

Machine and service credentials are unique per service, scoped to least privilege, and held in restricted stores; they are never placed in source control, logs, chat, or documents. Customer tenant credentials are held in the dedicated restricted auth store and nowhere else. The cryptographic protection of stored and transmitted credentials is governed by the Cryptography and Encryption Policy.

3.7 Handling and compromise

Passwords are never shared, written down, or sent over insecure channels, and are entered only into the genuine system they belong to — never into a page reached from an unexpected link. Anyone who suspects a credential has been exposed changes it immediately and reports the event under the Incident Response and Business Continuity Policy; reporting a suspected exposure is always the right call and is treated blame-free.

4. Responsibilities

The Security Owner owns this standard, verifies as part of each quarterly access review under the Access Control Policy that multi-factor authentication is in place on the accounts that require it, and handles reported credential exposures. Every member of staff manages their credentials in line with this policy and reports suspected exposure without delay.

5. Exceptions

Where a system cannot meet a requirement of this policy — for example, a platform that does not support multi-factor authentication — an exception must be requested in writing, assessed for risk, approved by the Founder, time-bound, recorded, and paired with a compensating control. Open exceptions are revisited at each quarterly access review.

6. Review

This policy is reviewed at least annually, whenever there is a significant change, and when the guidance it is informed by (NIST SP 800-63B) materially changes. The document owner maintains its version history.