Request a Demo
// PRIVILEGED ACCESS · MODULE 04

Rotate, reveal, and audit
privileged credentials.

SecureHive Privileged Access manages AD, cloud, and infrastructure secrets inside the operating platform that already runs your security program — one identity graph, one audit surface, one deployment. Not another standalone vault.

NOW IN BETA · ONBOARDING DESIGN PARTNERS

Standalone vaults solved storage. They broke everything else.

Privileged access became its own silo — a separate console, a separate audit trail, and a separate line item, disconnected from the security program it exists to protect.

Siloed from GRC, SOC, and identity — every rotation event lands in a different audit trail than the controls that require it
Rotation policies drift from compliance frameworks — no closed loop between what the framework mandates and what actually rotated last night
Reveal audit is incomplete or missing — “who saw the credential, and when” is the SOC 2 question standalone vaults keep failing
The economics don't work — $60–200 per privileged account per year, and 6–12 month deployments before the first credential rotates

One platform. Not another silo.

Privileged Access is a module of the SecureHive operating platform — it inherits the identity graph, audit surface, and executive reporting the rest of your program already runs on.

01

One identity graph

Privileged accounts live in the same registry as SOC alerts, GRC controls, and AI governance findings — one graph connects who has access to what, and why it matters.

02

One audit surface

Reveal events, rotation runs, and agent enrollments flow into the same executive dashboard as every other module. One place to answer the auditor.

03

One deployment

The same tenant, the same SSO, the same role-based access as the rest of the platform. No second console to secure, no second vendor to assess.

What ships in the module today

Functionally complete and running now — account lifecycle, policy-driven rotation, governed reveal, and a full audit trail.

Policy-driven rotation

Full account lifecycle with rotation policies that define cadence, complexity, and scope — rotation happens on schedule, not when someone remembers.

Destination catalog

Push rotated credentials where they need to land — Active Directory, Azure IAM, AWS IAM, and custom destinations — carried out by a lightweight connector agent inside your network.

Governed reveal

Request an ephemeral account or reveal a rotated password through time-limited tokens — redacted end-to-end in transit and logs, never sitting in a browser tab or a log line.

Originator attribution

Every event answers three questions: who requested, who approved, who revealed. Attribution is captured at the wire, not reconstructed after the fact.

Reveal Desktop

The app your team uses to request ephemeral accounts and rotated passwords — native on macOS (Apple-notarized), Windows (Authenticode-signed), and Linux, plus a CLI for scripted workflows.

Workload tokens

Scoped tokens for CI pipelines, backup jobs, and monitoring agents — machine access governed like human access. Landing during Beta.

// REACH · CLOUD
DESIGN-PARTNER PROGRAMME

Standing cloud access is the credential nobody rotates

The privileged account that survives every audit is the one in your cloud provider — a long-lived key or a role somebody was granted in 2023. Privileged Access reaches it without asking you to install anything on the target.

Agentless just-in-time on AWS, Azure, and GCP

Access is provisioned through each provider's own control plane — no agent on the instance, nothing to deploy to a machine you may not own. A session exists for as long as it was granted and no longer.

Cloud roles requested like any other target

An IAM role becomes something a person requests, receives for a bounded window, and returns. Roles are default-deny: one has to be granted explicitly before anyone can ask for it, so an unclassified role is never quietly requestable.

Your account, your credentials, never ours

Provisioning uses a role you grant us with an agreed external identifier. If that configuration is incomplete, the request fails rather than falling back — our own cloud identity is never used against your resources.

Expiry that does not depend on us remembering

Where a provider can enforce its own expiry, we use it, so a missed revoke degrades to an expired credential instead of a live one. Where a session genuinely cannot be withdrawn early, we report that plainly rather than showing a green tick.

// REACH · SERVICE ACCOUNTS
DESIGN-PARTNER PROGRAMME

The accounts nobody owns, and everybody depends on

Service accounts are where privileged access actually breaks: non-expiring passwords, unknown consumers, and a rotation that takes production down. The work here is finding them, rotating them safely, and — where possible — removing the need for them.

Discovery, with the risky ones surfaced first

Enumerates service accounts across the directory and ranks them by what actually makes one dangerous — a stale or non-expiring password combined with an exposure that makes it worth attacking.

Rotation that includes everywhere the password is used

A service account password lives in scheduled tasks, services, and application pools. Rotation updates the account and its usages together — and if a usage fails, the whole change is rolled back rather than left half-applied.

Delivery into the stores your applications already read

New credentials are pushed to AWS Secrets Manager, Azure Key Vault, Google Secret Manager, or Kubernetes secrets. Partial delivery is reported as partial — never as success — because a store holding a stale credential is a security fact.

Applications that fetch at start-up

For workloads that cannot read a secret store, a scoped machine token fetches the current credential directly. Scope is explicit: a token with none is granted nothing.

Paired accounts for zero-downtime rotation

Two accounts alternate, and the standby is proved to work before anything is pointed at it. There is never a moment when the credential in use is one that has not been verified.

An advisor that argues for fewer secrets

Every service account is assessed for whether it could become a managed identity with no password at all. The measure we report is how many secrets you have removed — not how many you have vaulted.

// REDUCE · THE DIFFERENCE

Traditional vaults were built to store. This was built to reduce.

Three things decide whether privileged access actually gets smaller: whether you can REACH the credentials a vault cannot, whether the estate REDUCES rather than grows, and whether you can PROVE what happened. The incumbents solved storage two decades ago and have been adding consoles to it ever since.

Deployed over 6–12 months, with professional services before the first credential rotates

A module of a platform you already run — same tenant, same sign-on, same roles

An agent installed on every target before it can be managed

Cloud targets reached agentlessly through the provider's own control plane

Rotation changes the vault entry and leaves you to find what broke

Rotation updates every place the credential is used, and rolls back if one fails

Success reported whenever the API call returned

Partial delivery reported as partial, and un-revocable sessions reported as such

A separate console and a separate audit trail from the program that requires it

Reveal and rotation land in the same audit surface as your controls and your SOC

Priced per vaulted account, so the incentive is to vault more of them

Measured on secrets removed, with an advisor that works to shrink the estate

Works with the identity systems you already run

Two pieces on your side, both signed by us: a lightweight connector agent inside your network that takes rotation instructions from the platform and executes them against AD and your servers, and Reveal Desktop — the app your team uses to request ephemeral accounts and rotated passwords.

Active Directory / LDAP

Rotation and ephemeral accounts executed on-prem by the connector agent, instructed by the platform

Azure IAM

Cloud asset discovery and rotation

AWS IAM

Cloud asset discovery and rotation — early access

Reveal Desktop

Request ephemeral accounts and rotated passwords — macOS, Windows, and Linux, Gatekeeper and Authenticode signed

Reveal CLI

Scripted reveal for admin and automation workflows

Webhook hub

Rotation and reveal events pushed to SIEM, ticketing, and chat

// PRICING

Sized by your organization — never by what you put in the vault

One rule: you sit in the lowest band that covers both your headcount and the systems we protect. Every band includes unlimited vaulted accounts, unlimited operators, and unlimited reveals and rotations.

Starter

$500/month
Up to 250 employees
100 targets included

Growth

$1,200/month
Up to 1,000 employees
400 targets included

Business

$2,500/month
Up to 5,000 employees
1,500 targets included

Enterprise

$5,000/month
Up to 15,000 employees
5,000 targets included

Above 15,000 employees or 5,000 targets — custom terms.

A target is a system Privileged Access rotates into, provisions access on, or delivers secrets to — a server, a cloud account, a cluster, a secrets store. Never a credential: one domain controller with 400 service accounts is one target, and retiring 399 of them to managed identities changes your bill by nothing.

The estate that costs $300K–$1M a year at $60–200 per vaulted account lands here at a flat band fee.

Beta design partners lock today's band rates at GA.

Built to clear a higher bar

A credential platform has to be more defensible than the systems it protects. This is the posture it ships with.

AES-256-GCM envelope encryption — every credential is sealed with its own key, wrapped by a root key held in AWS KMS that cannot be exported or read by us
Cryptographic tenant isolation — one organization's credential cannot be decrypted under another's identity, enforced by the key service itself rather than by a query filter
Signed binaries — macOS builds Apple-notarized, Windows builds Authenticode-signed under an EV certificate, with RFC 3161 trusted timestamps
Full audit trail with originator attribution — every request, approval, and reveal tied to a named identity
SOC 2 Type II ready — external security review and commissioning underway
How a credential is actually held →
NOW IN BETA

We're onboarding design partners

Privileged Access is functionally complete and shipping today. It's in Beta while it completes external security review and its first design partners take it into production — which means the partners we onboard now shape where it goes next.

Beta partners lock today's band rates at GA and get roadmap input.