Palisade gives operators direct, SYSTEM-level administrative control over Windows endpoints from a browser. That power is exactly why the authentication, authorization, isolation, and credential-handling model below is the core of the product — and why it is defended in depth. This page is written for technical evaluators deciding whether to deploy the agent across a fleet.
1. Trust model & network architecture
Palisade is outbound-only. The endpoint agent opens an authenticated WebSocket out to the control plane; the control plane never connects in to the endpoint.
- No open inbound ports on the endpoint — no RDP, no WinRM, no VPN concentrator, no agent listener.
- Works behind CGNAT, NAT, and restrictive egress policies (only outbound 443 is required).
- Every remote action — terminal, file transfer, process control, device proxy — is multiplexed over that single authenticated connection; there is no second control channel to secure.
The agent runs as a Windows service (LocalSystem) so it can perform administrative tasks. That privilege makes the authorization model below the security center of gravity.
2. Transport security
- All operator and agent traffic is TLS 1.2+ (TLS 1.2 / 1.3 only — TLS 1.0/1.1 are not offered), terminated at a dedicated edge with forward-secret ECDHE cipher suites (AES-GCM / ChaCha20-Poly1305) and auto-renewed certificates.
- Production and the internal pre-release channel run on separate hosts, databases, and certificates — no shared state.
- The device-UI proxy issues per-session wildcard subdomains so each proxied session is origin-isolated in the browser; cookies and storage cannot bleed across sessions.
3. Authentication
Operator sessions. Login issues a random bearer token (32+ bytes of entropy). The token is never stored in plaintext — only its SHA-256 digest is persisted, so a database dump yields no usable session, agent, enrollment, or proxy tokens. Sessions are server-side and time-boxed; expired sessions are rejected on every request and every WebSocket upgrade.
Passwords are hashed with bcrypt.
Multi-factor (TOTP). 2FA with single-use recovery codes. A session that has passed a password but not yet completed MFA is rejected by every protected endpoint and WebSocket upgrade — a half-authenticated session reaches no tool. Sensitive account operations additionally require step-up re-authentication (a session authenticated within the last few minutes).
Agent identity. Devices enroll with a single-use enrollment token (hashed at rest) and receive a per-device agent token (32 bytes of entropy, stored only as a SHA-256 digest). Every agent message is authenticated by that token; revoking a device invalidates it. Short-secret comparisons are constant-time to avoid timing leaks.
4. Authorization (RBAC)
Access is governed by roles with granular, per-capability permissions, enforced server-side on every privileged operation. Owner/Admin have full access; Technician and Viewer have configurable defaults with per-organization overrides. Each capability is gated independently — terminal, file manager, task manager, services, user manager, screen preview, device remote access (proxy / Telnet / SSH), scripts, BitLocker, and device/folder/network operations.
Defense in depth on the agent channel. Because the agent runs as SYSTEM, two independent gates apply: (1) opening a tool socket requires the matching permission, and (2) every browser→agent message is validated against an explicit per-tool allowlist — anything not on the list is dropped and logged. This prevents a user holding one tool's permission from sending another tool's commands over the same socket. An arbitrary-binary execution path was removed in favor of an audited, purpose-built exec path.
5. Multi-tenant isolation
Every device, network, credential, audit record, and session is scoped to an organization, and that scope is applied on every query, mutation, and WebSocket route — cross-tenant reads are not expressible in the data layer. Tenants have separate device lists, credential stores, and audit trails; one console can host many isolated client organizations.
6. Remote-session security
| Session type | Authentication | Additional controls |
|---|---|---|
| PowerShell / cmd terminal | session + terminal permission | real ConPTY; per-message allowlist |
| Device web-UI proxy | session + remote-access permission | per-session token bound to the originating client IP (a leaked URL can't be replayed elsewhere), short TTL, target validated against the org's scanned nodes, isolated per-session subdomain |
| Telnet / SSH | session + remote-access permission | target must be a scanned node in the org with the matching port open; credentials are pass-through only |
| Screen preview | session + screen-preview permission | streamed over the authenticated channel |
Device credentials entered for a proxy/Telnet/SSH session are held in process memory for the life of the session only — never written to disk, never persisted to the database, never written to logs. The proxy performs the device's HTTP auth agent-side so the secret never round-trips through the browser.
7. Secrets & credentials at rest
- Tokens (session / agent / enrollment / proxy): stored as SHA-256 digests, never plaintext.
- Passwords: bcrypt.
- Stored secrets (e.g. escrowed keys, integration config): envelope-encrypted with AES-256-GCM (random IV, authentication tag) under a 32-byte key, with domain-separated keys so compromise of one does not expose another. A Vault Transit / KMS scheme — where the master key never leaves the KMS — is selectable per deployment.
8. Audit logging
Privileged actions are written to an append-only audit event log, scoped per network/organization and surfaced in-dashboard, with actor, action, target, and timestamp. A scheduled job enforces retention.
9. Summary
| Concern | Control |
|---|---|
| Inbound attack surface | None — agent is outbound-only over TLS |
| Session tokens at rest | SHA-256 digest only; server-side expiry; MFA gate |
| Passwords | bcrypt |
| SYSTEM-level tool abuse | RBAC + per-message-type WebSocket allowlist |
| Cross-tenant access | Organization scoping on every operation |
| Proxy URL replay | Per-session token, IP-bound, short TTL |
| Device credentials | In-memory only, never persisted, never logged |
| Secrets at rest | AES-256-GCM envelope encryption, domain-separated keys, KMS option |
| Accountability | Append-only audit log with retention |
Have a question this page doesn't answer, or want to report a vulnerability? Reach us at security@palisadenetworks.com.