Vendor demo comparison checklist

The rows, by dimension

• Identity (3): Whether every session is tied to one named person, with a second factor.
• Scope (4): What a connection can reach, and what it can change, once it is made.
• Lifecycle (5): How access is inventoried, granted, seen and removed when the reason for it ends.
• Evidence (4): What is recorded about each session, for how long, and whether you can take it with you.
• Availability (6): Whether access exists only when it is needed and approved, and how it behaves when something fails.
• Fit and commercial (9): Deployment, protocols, onboarding, support and price. Important for choosing, lower priority for governance.

What is in the file

1. Read me first. How to use it, what each evidence status means, and why it is guidance, not a security audit.
2. Context. Your buyer type, sites, machines, external suppliers and current access methods, and whether remote support is business-critical.
3. Requirements. The 31 rows with why each matters, what to ask, the evidence to request, what a weak answer looks like, and a default priority for machine builders, operators and integrators.
4. Vendor comparison. Three vendor columns, each with the answer, an evidence status (Verified in demo, Documented only, Claimed, Not answered, Not applicable) and notes.
5. Demo script. 7 scenarios to ask for live, with the evidence to expect and follow-up questions.
6. Summary. Formulas only, no overall score: per vendor, the Must rows for your buyer type and how many are verified in a demo, documented, only claimed or not answered, plus the Must rows still open.
7. Action plan. The unresolved Must rows with the evidence to collect, stakeholders, next step, owner and date.

Guidance, not a security audit. Completing it does not show that any product or setup is secure.