Console desks · Security admin

Keys, rotations and step-up policies

Security owns the platform’s control plane: the key inventory and rotation ceremonies, the step-up policies that force fresh authentication before privileged acts, and the access review surface. Changing the rules is itself a privileged act that lands in the audit log.

A recorded run of this exact journey — every step below, performed live on the platform, with every click shown (about 3 minutes).

You are

Ama Mensah

Open the operator console → admin.blackant.tech

Supporting role

Kojo Asante (second key holder)

Open the operator console → admin.blackant.tech

Run a key rotation ceremony

1
Open Security → keys.
http://admin.blackant.tech/security
Expect · The key inventory with ages, custodians and ceremony history.
2
Request a rotation (step-up: security.key_rotation).
/security
Expect · The request records purpose and scope, then waits for a second security actor. Dual control is required on this policy.
3
Have the second holder approve; watch the ceremony record.
/security
Expect · The rotation executes as a recorded ceremony with both names on the evidence. Rejection records its reason just as durably.

Tune the step-up regime

4
Review the privileged-action policies.
http://admin.blackant.tech/security
Expect · Every privileged key (offering.launch, distribution.approve/execute, register.freeze, eligibility.override, access.role_escalation, security.*, account.recovery) with its freshness window and dual-control flag.
5
Change a policy window (step-up: security.policy_change).
/security
Expect · The change itself demands a fresh proof and lands in the audit log with before/after values.
6
Review sessions and access.
http://admin.blackant.tech/settings/roles and /audit
Expect · Role grants, suspensions and every step-up grant/denial are all auditable events.

That is every act this role can take.Pick another user type →