A security page should answer the login questions that every enterprise buyer asks, in plain terms and with only claims you can back up: which single sign-on (SSO) options you support and how a customer asks for setup, which multi-factor authentication (MFA) methods exist and who can require them, how sessions, passwords and recovery work, what your audit logs record and for how long, and how a customer removes people who leave their company. Publishing those answers once means fewer questions arrive in the first place, and the ones that do arrive can be answered by pointing to a page your sales and security teams already agree on.
This post is for a founder, CTO or head of platform at a small B2B SaaS company that keeps getting security questionnaires from larger prospects. It covers what to publish in advance. If you are looking at a questionnaire that has already landed, our posts on what vendor security questionnaires ask about login and who answers security questionnaires at a 50-person SaaS cover that side.
How does a public security page help with enterprise reviews?
A buyer’s security team usually starts a review by reading whatever you have published, and a page that already answers the common login questions lets you answer many questionnaire items by pointing to it. Two widely used standard questionnaires, the Cloud Security Alliance’s Consensus Assessments Initiative Questionnaire (CAIQ) and the Shared Assessments Standardized Information Gathering (SIG) questionnaire, both contain a large block of identity and access questions, so a page that covers login well removes a visible share of the work for both sides.
There is a second benefit that is easier to miss. When answers live in a spreadsheet that someone rewrites for each prospect, two customers can receive slightly different answers about the same feature, and a sharp reviewer will notice if they compare notes. A published page forces one set of wording that everybody can check.
What does a buyer’s security team look for first?
In practice they look for whether you name specific capabilities, because vague statements such as “we take security seriously” tell them nothing and usually trigger a longer questionnaire. They also look for dates (when the page was last reviewed), a contact address for security questions, and a clear split between what is available to every customer and what depends on a plan.
What should the login section say, topic by topic?
Write each topic as two or three plain sentences that state what exists, who controls it and where a customer starts. The rest of this section is a suggested structure.
Single sign-on
State the protocols you support (SAML 2.0 and OpenID Connect are the common pair), whether the customer connects their own identity provider, and how they request setup, for example through their account manager or a settings page. If SSO is only on a higher plan, say so, because buyers who find a plan limit late in procurement tend to lose trust in the rest of the page.
Multi-factor authentication
List the methods you support (authenticator app codes, passkeys or security keys, and so on) and say who can require them: only individual users, or a customer administrator for everybody in their organization. Reviewers care most about the second case, because “available” and “enforced” are different answers, and the questionnaire will ask which one you mean.
Sessions, password policy and account recovery
Say how long a session lasts and whether it expires after inactivity, and describe your password rules in one paragraph. For passwords, the current NIST guidance in SP 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management (revision 4, July 2025) says verifiers shall not require periodic password changes, and should force a change only when there is evidence of compromise, so a page that explains a length-and-screening policy is more defensible than one promising 90-day rotation. Describe account recovery in plain terms as well, since recovery is where many account takeovers happen.
Audit logs
State what is recorded (sign-ins, failed sign-ins, administrative changes), how long it is kept, and whether customers can see or export their own events. Do not publish a retention number you have not confirmed in your system, because a wrong figure on a public page is worse than a general statement.
Removing people when they leave a customer’s company
Enterprise buyers worry about former employees keeping access. Explain how a customer deprovisions people: manually through an admin console, automatically through SCIM (System for Cross-domain Identity Management, the standard that lets a customer’s directory create and remove accounts in your product), or by disabling them at their own identity provider. Our post on removing customer leavers from your product goes through the options.
What should a security page not claim?
Leave out anything you cannot show a document for. That includes certifications and reports you do not hold yet, since a buyer may ask to see the report under NDA and a “coming soon” in the questionnaire is much easier to explain than a withdrawn claim. If you are deciding between report types, SOC 2 Type 1 or Type 2 lays out the difference.
The same applies to uptime and support promises. An uptime figure on a page reads like a commitment, so publish one only if a contract or SLA backs it, and describe support hours as they really are. Our post on what to promise an enterprise customer about login uptime explains how to size that promise.
Who owns the page, and how often is it reviewed?
Give the page a single named owner, usually whoever answers questionnaires today, and put a review date on it. A sensible routine is a review each quarter and an extra one whenever you change how login works, such as adding SSO or changing session settings. Sales should treat the page as the source for answers, and the owner should update it first and the questionnaire answers second, so the two do not drift apart. If nobody on the team has security as a job title, who owns login without a security hire covers how small teams assign it.
A short checklist for your security owner
- SSO protocols, how to request setup, and which plan includes it
- MFA methods, and whether a customer administrator can require them
- Session length and inactivity behaviour, password policy in plain words, and recovery steps
- Audit log contents, retention, and customer access to their own events
- How a customer removes people (admin console, SCIM, identity provider)
- Certifications and reports you actually hold, with a note on how to request them
- A security contact, a named owner and a last-reviewed date
FAQ
What is the difference between a security page and a trust center?
A security page is a public web page that describes your controls in prose. A trust center is usually a hosted portal that adds gated documents such as reports, subprocessor lists and policies behind an NDA or request form. Many small SaaS companies start with the page and add a trust center later, and the login section described here fits into either.
Should the page list every control in our questionnaire answers?
No. Publish the stable, high-level facts and keep detailed or sensitive material (network diagrams, exact configurations, penetration test findings) for questionnaires answered under NDA.
How detailed should the MFA section be?
Detailed enough that a reviewer can tell whether MFA is optional, available to administrators, or enforceable by the customer. One short paragraph with the methods and the enforcement options is normally enough.
Does a security page replace a SOC 2 report?
No, and it should not try to. The page tells a buyer what you do, and a report from an independent auditor is the evidence that you do it. The page is most useful for getting a buyer to the point of asking for the report, because their first questions have already been answered.
What to do next
Start by writing the five login sections above as drafts and have whoever answers your questionnaires check each statement against how the product really behaves. Then agree the final wording with sales, publish it with a review date, and use it as the first reference in every future questionnaire. If you want to see how a vendor structures this, the Skycloak security page shows how one vendor describes its controls.