One closed appliance per rack
Consoles for switches, firewalls and servers sit behind the SLC 9000 on its own management uplinks, instead of each device exposing a management surface.

By role
Every rack has management interfaces an attacker would love to reach. The SLC 9000 gathers them behind one closed appliance on its own network, and Percepxion puts your identity provider, roles and a named-user audit log in front of it.
Capabilities
Consoles for switches, firewalls and servers sit behind the SLC 9000 on its own management uplinks, instead of each device exposing a management surface.
Device login takes RADIUS, TACACS+, LDAP or local accounts, with Duo MFA through a RADIUS proxy. Percepxion adds SAML 2.0 SSO, group mapping, RBAC and MFA.
The Percepxion platform audit log records management actions against the named user, and the event log is queryable through the REST API.
No shell on the firmware, firmware signature checked at boot by the NXP LayerScape secure element, and default credentials unique to each unit.
Put every console behind one appliance on its own management network. Switch consoles, firewall management interfaces and server BMCs are reachable whenever the rack is reachable. Left alone, that’s a standing management surface in every rack. The SLC 9000 gathers those consoles behind one 1RU appliance with its own uplinks, so admin access goes through an appliance you control instead of every device’s own management port.
The cloud side doesn’t add an inbound path either. The SLC 9000 registers to Percepxion device-side first over an outbound-only MQTT connection, so there’s no inbound firewall rule to the console server.
Your identity stack decides, at both layers. On the device, login supports RADIUS, TACACS+, LDAP and local accounts, with Duo MFA through a RADIUS proxy. On Percepxion, SAML 2.0 SSO works with Okta, Azure AD or any SAML 2.0 provider, and RADIUS and TACACS+ group attributes map users into Percepxion groups. RBAC and MFA apply on top.
Scope follows the org chart. Percepxion organizes access by project, portal and organization, with three default roles and per-operation permissions, so a regional team sees its own console servers and nothing else.
The box starts clean, too. Default credentials are unique per unit and get changed at initial setup. There’s no shared vendor-wide password to hunt down across a fleet.
A platform audit log tied to named people. The Percepxion audit log records management actions against the named user, and the event log is fully queryable through the REST API, so you can pull it into your own retention system on your schedule. Session activity is audit-logged; individual keystrokes are not recorded.
Small, and deliberately so. SLC 9000 firmware exposes no shell. Containers, where you use them, run sandboxed at 256 MB of memory and one CPU core. Every unit verifies its firmware image signature at boot through the NXP LayerScape secure element before it’s allowed to start.
Every SLC 9000 SKU also includes a discrete TPM 2.0 chip. The TPM 2.0 chip is present on every SKU; GA firmware does not yet use it for encryption or attestation. The SLC 9000 is not FIPS certified. We’d rather you design around exactly what ships than find the gap in a review.
Questions
SAML 2.0 SSO runs on Percepxion, against Okta, Azure AD or any SAML 2.0 provider. The device takes RADIUS, TACACS+, LDAP and local accounts, with Duo MFA through a RADIUS proxy.
No. SLC 9000 default credentials are unique per unit and are changed at initial setup.
Session activity is audit-logged; individual keystrokes are not recorded.
The SLC 9000 is not FIPS certified.
The Product Selector opens with this page's filters applied. Add models to My List, then export it or email it for a quote.
Spec an SLC 9000