Authentication and Password Policy template (SOC 2)

1. Purpose

Stolen and guessed credentials remain the most common way into companies like Northwind Cloud Inc. This policy sets the rules for how people and systems prove who they are before they are given access: passwords, multi-factor authentication, single sign-on, sessions, recovery, and the credentials services use to talk to each other. It follows current guidance from standards bodies: long passphrases rather than complexity rules, breached-password checks rather than forced rotation, and multi-factor authentication that resists phishing.

2. Scope

This policy applies to all personnel of Northwind Cloud Inc and to every account, human or non-human, that authenticates to a company system, including:

• Workforce authentication through Okta and the applications federated to it.
• Authentication to the consoles and APIs of AWS and Vercel, GitHub, GitHub Actions, production databases and secrets managers.
• Local accounts on company laptops and phones managed by Kandji.
• Service accounts, API keys, tokens, certificates and SSH keys used by Northwind and its supporting systems.
• The authentication features of Northwind itself, which customers rely on to protect their own accounts.

3. Roles and Responsibilities

• Executive Management (Priya Natarajan, CEO) approves this policy and ensures that multi-factor authentication and password manager licences are funded for everyone, including contractors.
• Security Owner (Dana Whitfield, CTO) owns this policy, configures and monitors authentication settings in Okta, tracks multi-factor coverage, approves account recovery, and responds to credential compromise.
• Engineering enforces these requirements in the identity services of AWS and Vercel, GitHub and internal tools, manages non-human credentials, and builds the customer-facing authentication of Northwind to this standard.
• People Operations ensures multi-factor enrolment and password manager setup are completed during onboarding before other access is granted, and keeps recovery contact details current.
• All Personnel choose strong, unique credentials, enrol in multi-factor authentication, use the password manager, protect their second factor, and report suspected compromise immediately.

4. Policy Statements

• 4.1 Every person authenticates with a unique identity attributable to them. Generic, shared or role-named interactive logins are prohibited except for break-glass credentials governed by the Access Control Policy.
• 4.2 Multi-factor authentication is mandatory for every workforce account at Northwind Cloud Inc, without exception for seniority. Administrative accounts in Okta, the identity services of AWS and Vercel and GitHub use phishing-resistant methods such as FIDO2 security keys or passkeys; authenticator applications are acceptable elsewhere. SMS and voice codes are permitted only where no other method is offered and are recorded as an exception.
• 4.3 Applications that support single sign-on are integrated with Okta, and personnel sign in through it rather than with application-local passwords, which are disabled where the application allows.
• 4.4 Passwords chosen by people are at least 14 characters, with no maximum below 64 and no mandatory character-class rules. They are checked against known-breached password lists at creation and periodically and rejected if they appear. Passwords are not rotated on a fixed schedule; they are changed immediately when compromise is suspected, when they appear in a breach, or when a person who knew a shared secret leaves.
• 4.5 All work credentials are generated and stored in 1Password, provisioned for every person at onboarding. Passwords are not stored in browsers, spreadsheets, notes, chat or email, and the password manager's master password is a strong, unique passphrase protected by multi-factor authentication.
• 4.6 Work passwords are never reused across systems or as personal passwords. Personnel never share passwords, one-time codes or security keys with anyone, including colleagues, support staff or people claiming to be from Northwind Cloud Inc leadership.
• 4.7 Sessions are bounded: workforce sessions in Okta expire after no more than 24 hours, privileged sessions in AWS and Vercel after no more than 12 hours, and devices lock after 10 minutes of inactivity. Re-authentication is required for sensitive actions such as changing multi-factor settings or viewing secrets.
• 4.8 Non-human credentials such as API keys, service account keys, tokens and SSH keys have at least 128 bits of entropy, live only in the secrets manager or the platform's native secret store, are injected at runtime rather than committed to configuration, carry the narrowest permissions required, and are rotated at least annually and on suspected exposure. Short-lived federated credentials replace static ones wherever the platform supports it, and default or vendor-supplied credentials are changed before any system is connected to a network.
• 4.9 Authentication endpoints, including those of Northwind, enforce rate limiting and lockout or progressive delay after repeated failures, log every failed attempt, and alert through Datadog on patterns that indicate credential stuffing or brute force.
• 4.10 Account recovery and multi-factor resets are performed only after identity has been verified through a channel other than the one being recovered, such as a video call with a known colleague or a code sent to a verified personal contact held by People Operations. Requests arriving by email or chat alone are never actioned.
• 4.11 Northwind protects customer accounts to at least the same standard: customer passwords are stored with a slow adaptive hash such as Argon2id or bcrypt and a per-user salt, are never logged or transmitted in plain text, are checked against breached-password lists, and customers are offered multi-factor authentication.
• 4.12 Credentials travel only over encrypted channels, never appear in URLs, log lines, error messages or crash reports, and are masked in any interface that displays them.

5. Procedures

• 5.1 Onboarding enrolment. On the first working day, before any other access is granted, the new hire enrols in 1Password and registers at least two multi-factor methods in Okta, one of which is a security key or passkey for anyone with an administrative or production role. People Operations records completion and the Security Owner verifies it before approving the standard access bundle.
• 5.2 Monthly coverage check. The Security Owner exports multi-factor enrolment status for every account from Okta, the identity services of AWS and Vercel and GitHub, opens a ticket for any account without a compliant method, and suspends accounts still non-compliant after five business days. The export is retained as evidence.
• 5.3 Breached credential response. When Okta, the password manager or a threat intelligence source reports a work credential in a breach, the Security Owner forces a reset within one business day, revokes sessions, checks authentication logs for use since the breach date, and records the event.
• 5.4 Account recovery and lost factors. A person who has lost a password or second factor contacts security@northwindcloud.example. The Security Owner verifies identity by video call or through the personal contact details held by People Operations, removes the lost factor, revokes sessions, issues a bypass valid for no more than one hour, confirms a new factor is enrolled before it expires, and reviews recent sign-in activity for anything suspicious. Every recovery is logged with the verification method.
• 5.5 Non-human credential rotation. Engineering maintains the service account inventory from the Access Control Policy with a rotation date for each credential. Rotation happens at least annually, when a person with knowledge of the credential leaves, and on suspected exposure, and is performed through the secrets manager so that no person needs to view the new value.
• 5.6 Secret exposure. If a credential is committed to GitHub, pasted into chat or otherwise exposed, the finder reports to security@northwindcloud.example immediately. Engineering revokes and rotates it within four hours and reviews logs for use of the exposed value; the Security Owner records an incident. Secret scanning alerts in GitHub are triaged within one business day.
• 5.7 New application onboarding. Before an application is approved under the Acceptable Use Policy, the Security Owner confirms whether it supports single sign-on and multi-factor authentication, integrates it with Okta where possible, and records any application that cannot meet this policy in the exception register with its compensating control.
• 5.8 Customer authentication review. At least annually, and before any change to login, password reset or session handling in Northwind, Engineering reviews the implementation against 4.9, 4.11 and 4.12, records the review, and includes authentication flows in the security testing described in the Secure Software Development Policy.

6. Exceptions

Exceptions, for example a legacy application that cannot enforce multi-factor authentication or a device that cannot support a security key, are approved in writing by the Security Owner, recorded in the exception register with compensating controls and an expiry date no later than twelve months out, and reviewed at each annual review. No exception permits sharing credentials, disabling multi-factor authentication on an administrative account, or storing secrets in source code.

7. Enforcement

Accounts that do not meet this policy are suspended until they do. Personnel who share credentials, disable their own multi-factor authentication, store secrets outside approved systems, or approve authentication prompts they did not initiate are subject to the disciplinary process in the Acceptable Use Policy, up to and including termination. Engineering leads are accountable for non-human credentials in their systems found to be over-privileged, unrotated or exposed.

8. Review Cadence

The Security Owner reviews this policy at the annual policy review, after any incident involving compromised credentials, and whenever Okta or the identity services of AWS and Vercel introduce authentication capabilities that would strengthen these controls. Revisions are approved by Priya Natarajan, CEO and recorded in section 9.

9. Revision History