Defense & national security use case · ServiceNow + Okta + Microsoft 365
Privileged access change with approval
Privileged access requests travel through tickets and side conversations. Grants are made manually and reviews cannot reconstruct the decision. Privileged access is granted only after named approval, with every change recorded.
Architecture
One governed run
How it starts: A ServiceNow request starts the run through the ServiceNow trigger source.
Step by step
How the process runs
- 01
Request
A ServiceNow ticket carries the request and justification.
- 02
Policy
Rules + Code checks role eligibility and separation of duties.
- 03
Named approval
The access owner approves or rejects, in Teams or the run.
- 04
Grant
Okta role, group or user changes run.
- 05
Record
Outcome posts to the ticket and an email confirmation is sent.
Control
Human decision and exception path
Human decision
Every privileged change requires a named approver. Time-bound grants are removed by a scheduled follow-up run.
Exception path
- Policy violations reject the request with a reason.
- Okta errors keep the ticket open.
- Expired approvals require a new decision.
Evidence
What gets audited
- Request and justification.
- Policy result.
- Approver identity and time.
- Okta operations and removal of time-bound access.
Nexus runs on premises, in private or sovereign cloud, or air-gapped. Credentials stay in the vault, roles decide who can approve, and the execution record stays inside your deployment boundary.
Sovereignty and deploymentRelated
Patterns, connectors and next steps
- Microsoft 365-Okta integration
Integration pattern · Identity changes and collaboration follow-up happen together, under policy.
- ServiceNow connector
55 pre-built actions
- Okta connector
42 pre-built actions
- Microsoft 365 connector
45 pre-built actions
- Governed self-service
Requests with policy and approval built in.
- Cloud incident to controlled remediation
Another defense & national security use case.
FAQ
Questions about this use case
- Does Nexus replace any of these systems?
- No. Each system keeps its own records. Nexus runs the process between them and records each decision.
- How does the run start?
- A ServiceNow request starts the run through the ServiceNow trigger source.
- What if a step is not covered by a pre-built action?
- It runs through an API, protocol or database call, or as Rules + Code in Python, Bash, Go, Java, .NET, PHP, PowerShell or JavaScript/TypeScript, with the same approvals and audit.
Use case review
Discuss this use case
Bring your version of the process. We will map the systems, approvals and evidence it needs.