Security · Identity and access
Who you areis only halfthe question.
Zyposoft designs identity and access for the software we build and the systems we connect: one sign-in through the identity provider you already run, roles from your own directory, access that also depends on the situation, and every decision written down.
Five questions · 1
Are you who you say you are?
People sign in once, through the identity provider you already run. Sessions expire, and when someone leaves on your side, they leave here too.
Five questions · 2
What is your job here?
Roles come from your own directory, grouped by what people do, so there is no second list to keep in step. Conflicting duties are blocked when access is granted and again when it is used.
Five questions · 3
Does the situation allow it?
A job title is not enough. The team someone is in, where they are working, their shift and the piece of work in front of them all count, and the rule is set per role.
Five questions · 4
What if you genuinely must override it?
Emergency access is a deliberate door, not a hole: it asks for a reason, expires on its own, and is reviewed afterwards.
Five questions · 5
What about the systems, not the people?
Services and integrations get their own credentials, scoped narrowly, revocable, and recorded on the same trail as people.
What gets written down
Every decision, including the refusals.
Who opened what, when, from where, with which role at the time, whether it was an override and the reason given, and every attempt that was refused.
The refusals matter as much as the approvals: someone trying to open what they should not is often the first sign that something is wrong.
The awkward questions
The ones your security team will ask on the first call.
- Someone left last month and still has access.Roles come from your directory, not a list we keep. Disabled on your side means disabled here.
- Some people move between teams all the time.Then team alone is the wrong rule for them. Context is set per role, so it can follow the work instead.
- Isn't break-glass a hole in the security?It is a deliberate door. The alternative is people sharing logins in an emergency, which leaves no record at all.
- We need to prove this to an auditor.Access records can be searched and exported. Who may run those searches, and how long records are kept, we set up with you.
Setting it up
Agreed with your team, then tested to break.
Which roles exist, what context each is bound to, who may break glass and how long records are kept are your decisions. We set them up with you, then try every way around them.
- Connect your identity provider: Single sign-on, Test accounts, What happens when it is down.
- Agree the roles: The list of roles, How they map from your directory, Who approves changes.
- Decide what context means: For each role, Team, place, shift, The work in hand.
- Set up break-glass properly: Who may use it, What it asks for, Who reviews it, how quickly.
- Try to break it: Wrong role, Stale session, Nothing leaks in an error.
- Keep reviewing it: Who has what, Overrides and refusals, After every reorganisation.
Talk to our security team
Possible to override. Impossible to do quietly.
One sign-in through the identity provider you already run, roles from your own directory, and access that depends on the situation, with every decision on record.
How this ends up configured is your team's decision: which roles exist, what context each is bound to, who may break glass and how long records are kept are agreed during the work. Specific protocols, providers and retention periods are confirmed per engagement rather than claimed on a web page.