IMTerm Security

Enterprise-grade security built in from the ground up

Authentication Methods

Method	Description	Config
Local / Built-in	Bcrypt password hashing, per-user accounts managed via admin console	`auth.mode: local`
LDAP / Active Directory	Bind authentication, group-to-role mapping, supports TLS and StartTLS	`auth.mode: ldap`
Azure AD / Entra ID (OIDC)	OpenID Connect redirect flow for Microsoft Entra ID. Group-to-role mapping from Azure AD group membership claims. "Sign in with Microsoft" button on the login page. Configured via imterm-setup Phase 6 or IMTERM_OIDC_* env vars.	`auth.mode: oidc`
OIDC / OAuth2	OpenID Connect, Okta, Google Workspace, and any compliant IdP	`auth.mode: oidc`
SAML 2.0	SP-initiated SSO, ADFS, PingFederate, Okta. Signature validation via goxmldsig	`auth.mode: saml`
Kerberos SPNEGO	Keytab-based, transparent browser SSO on Windows domain machines	`auth.mode: kerberos`
mTLS client certificates	Mutual TLS, client certificate presented at TLS handshake, mapped to user	`auth.mode: mtls`

RBAC Model

Role	Permissions
Admin	Full access, user management, configuration, audit log, session monitoring, all terminal operations
User	Sessions, file transfer, printing, macros, scripting, Agent Mode
View-Only	Observe active sessions, no keyboard input, no transfer, no print

All roles are enforced server-side. There is no client-side bypass path.

TLS

TLS 1.2 minimum. TLS 1.0 and TLS 1.1 are refused at the listener.
HSTS enforced with a 2-year max-age (Strict-Transport-Security: max-age=63072000; includeSubDomains).
Security headers on every response: Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin.
WebSocket connections inherit TLS from the nginx/reverse proxy layer; origin validation enforced in server mode.

FIPS 140-2: A FIPS build is available using BoringCrypto (certificate 3678). Build with make build-fips. The FIPS binary uses BoringSSL for all cryptographic operations and refuses non-compliant cipher suites.

Audit Logging

96 structured IMTE message IDs, every event has a stable, documented ID.
JSON format, one JSON object per line, SIEM-ready (Splunk, Elastic, QRadar).
Covers: every login, logout, failed authentication, session start/end, file transfer, print job, admin action, and configuration change.
Log rotation: --audit-max-size flag, daily_rotation config key, configurable retention in days.

Session Security

Idle timeout, configurable per user or globally; session terminated and audit-logged on expiry.
Session recording, JSONL format, replay-capable, stored server-side.
View-only sharing links, generate a time-limited URL that grants observe-only access to an active session.
All session sharing events are audit-logged with the requesting user, target session, and timestamp.
Session tokens use HttpOnly, Secure, SameSite=Strict cookies. No session state in the browser.

Data Protection

No telemetry. No phone-home. IMTerm does not contact any external service at runtime.
License validated offline using HMAC-SHA256. No license server calls.
Passwords stored as bcrypt hashes (cost factor 12). No plaintext secrets anywhere.
No sensitive data stored in the browser, no localStorage, no sessionStorage for credentials.
Static binary, zero runtime library dependencies, minimal OS attack surface. Dependencies audited with go-licenses and npm audit.

Independent Security Review

IMTerm v2.3.x underwent an independent AI-assisted code security review (Fable5) covering all Critical, High, Medium, and Low findings. All findings were remediated before customer delivery.

Path traversal prevention in print archive
Print archive ownership enforced per user
No default credentials in server mode
X-Forwarded-For only trusted from configured trusted proxies
Session cookies: HttpOnly, Secure (auto-detected), SameSite=Strict
Account lockout: HTTP 429 with JSON response and audit event
AID command injection prevention (allowlist)
Goroutine panic recovery (one bad session cannot crash the server)

Security contact: security@infomanta.com

The only terminal emulator with built-in capacity management

Every other terminal emulator accepts connections until the server runs out of memory - then crashes, hangs, or starts dropping sessions silently. IMTerm is different.

Before you install: the setup wizard calculates exactly how many servers you need based on your hardware and user count.
At runtime: when a node reaches its configured session limit, the health endpoint returns HTTP 503. Your load balancer automatically stops sending new users to that node.
In the admin console: every node shows a capacity bar. Green = healthy, yellow = getting full, red = at limit.
For upgrades: drain a node (admin console, one click), upgrade it, bring it back. No downtime. The spare node in the cluster exists for exactly this purpose.

PowerTerm WebConnect had none of this. When the server was overloaded, users experienced slow response or could not connect - with no warning and no automatic recovery. IMTerm turns capacity management from a crisis into a routine operation.

Calculate your cluster size →

Security Disclosure

To report a security vulnerability in IMTerm, contact support@infomanta.com. Please include a description of the issue, steps to reproduce, and the IMTerm version. We respond to all reports within 2 business days.