Capabilities

Everything access control should be, and nothing it shouldn't.

Ventureship SSO does one job completely: it decides who may open which application, applies that decision everywhere at once, and proves afterwards that it did.

One identity per person

A person is the same person in every connected application. Duplicate accounts stop accumulating, and the identity you withdraw is the only one that ever existed.

Segmented by design

Customer-facing and internal applications are registered separately, and every identity carries the segment it belongs to. An internal door will not open for a customer identity.

Central entitlement

Whether a door opens is decided at the moment it is tried, from one source of truth — not from a list each application keeps and forgets to update.

Revocation that reaches everywhere

Withdrawing an identity withdraws it across the estate in the same moment, with the exact time recorded. There is no window where a closed account still opens something.

Evidence as it happens

Every grant, denial and administrative change is written down when it occurs, append-only, with the actor and the address it came from.

Administration without exposure

The administrative console is unlisted, rights are re-read from the source of truth on every request, and there is no path to it from anywhere a customer can reach.

Segmentation

Separation you can point at, not a label you can toggle

Keeping customers out of internal systems is the control most often claimed and least often enforced. Here it is a property of the fabric, not a promise each application makes.

Segment travels with the identity

Every identity is either customer-facing or internal, and that answer is carried into every access decision. An application cannot decide for itself which one it is dealing with.

Applications declare what they are

Each registered application is marked customer-facing or internal at registration. Internal applications refuse customer identities outright, before any handoff is issued.

Handoffs cannot cross

Proof of identity is bound to the one application it was issued for. It cannot be presented to a second application, in either segment, at any point in its short life.

The record shows the segment

Every access event is logged with the segment it belonged to, so a reviewer can ask "did any customer identity reach an internal application" and get a real answer.

Connected applications

Applications join a register, not a free-for-all

An application cannot participate until someone with the authority to do so has registered it and declared where it is allowed to send people back to.

Declared return addresses

Each application registers the exact addresses sign-on may return a person to. Anything else is refused. There are no wildcards, because a wildcard is how an identity provider becomes a redirection tool for someone else.

Credentials that can be rotated

Each application holds a secret used to redeem sign-on handoffs. It is stored only as a hash, can be rotated at any moment, and a rotation takes effect immediately.

Disable without deleting

An application can be taken out of service in one action while its history stays intact for review. Nothing is lost by turning something off.

Short-lived, single-use handoffs

The proof passed to an application expires within minutes and can be redeemed exactly once. A copied handoff is worthless by the time anyone could use it.

Adoption

What the first four weeks look like

No estate moves at once. This is the sequence we run, and the point at which each step becomes provable.

  1. Week one — inventoryThe applications that matter, their owners, and which of them face customers. Most organisations learn something uncomfortable here.
  2. Week two — first applicationOne application registered, return addresses declared, sign-in and revocation proven end to end.
  3. Week three — policyRoles, segments and exceptions agreed once and written down. From here on, every application receives the same answer.
  4. Week four — first waveThe next group of applications joins under the policy already agreed, and the audit trail starts covering real traffic.

See it against your own applications

Bring one application and the list of people who should be able to open it. That is enough to prove the whole model.

Talk to the team