Field note 01 · Updated July 29, 2026
Secure access is a route, not a checkbox.
1. Endpoint and software
- Identify supported Windows versions and update ownership.
- Record whether the package is installed or portable.
- Define how configuration backups are protected.
- Confirm the edition and permitted organizational usage.
2. Trust and identity
- Document direct hosts, gateways, proxies, and DNS assumptions.
- Define host-key verification and changed-key escalation.
- Choose approved authentication methods and key storage.
- Record MFA prompts and failure recovery.
3. Session behavior
- 01ForwardingList local, remote, dynamic, and X11 forwarding that is actually required.
- 02TransferTest SFTP or SCP browsing, destination permissions, partial transfers, and retry behavior.
- 03LoggingDecide whether terminal logs are required, where they live, and who may read them.
- 04RecoveryExercise expired credentials, a changed host key, a failed gateway, and interrupted transfer.
4. Ownership record
| Decision | Owner | Evidence | Review trigger |
|---|
| Approved access path | Network/platform owner | Route diagram and test | Gateway or network change |
| Authentication method | Identity/security owner | Policy and pilot evidence | Control or provider change |
| Session convention | Operations lead | Published taxonomy | New environment or team |
| Transfer handling | Data/system owner | Test case and retention rule | Data classification change |
Checklist questions
Does MobaXterm make an SSH route secure by itself?
No client replaces server configuration, identity policy, network controls, and operator behavior. Review the complete path.
Should every session enable X11 forwarding?
No. Enable only what the workflow requires and test server-side prerequisites and exposure.
When should this checklist be repeated?
Before a pilot, before broad rollout, and after material changes to gateways, identity, endpoints, software, or data handling.