Access requests and access reviews, inside ServiceNow.
Staff ask for access in Employee Center. The right people approve it. Your identity system, or a ServiceNow task, delivers it. Reviewers confirm it in user access reviews, with evidence an auditor can test. Nothing to host, and no identity engine required.
Works with SailPoint today, Microsoft Entra coming soon, or with no identity engine at all
Every square is one grant. Nia Bishop left on 22 August and still holds a high-risk HR role that conflicts with Payroll Approver.
See it working on a live instance.
A request, an access bundle, My Access, a review, and the setup behind them, all recorded in ServiceNow.
Three starting points.
Native governance in your instance
You run ServiceNow with Active Directory or Entra, and access reviews live in a spreadsheet. Warde gives you requests with proper approval, delivery as ServiceNow tasks, and reviews with evidence. Typically 1,000 to 10,000 staff.
Requests and reviews where staff already are
You own a governance product, and staff still ask for access by ticket. Warde puts requests, approvals, user access reviews and My Access in Employee Center. It hands delivery to your engine through a connector, or to a named task until your connector ships. Typically 3,000 to 15,000 staff.
Replace the home-built integration
You run IdentityIQ or Identity Security Cloud, with a custom ServiceNow integration somebody built years ago. Warde replaces it with a supported connector, adds user access reviews decided in ServiceNow, and keeps your options open on the vendor. Typically 15,000 staff and up.
Ask, approve, deliver, review.
One path for every request, whether a connector or a person does the work at the end of it. Removals and review revocations go down the same path.
One request
Search for access by name and put several applications in one request, for yourself or for somebody else. Duplicates, conflicts and missing prerequisites show before you submit.
The right people, in order
Manager, application owner, security: whatever chain your policy sets. Each approver sees what the access is, in plain words, and why it has come to them.
Your engine provisions it, automatically
Warde sends the approved change to your identity system, and the engine provisions it with no ticket and no manual work. Warde retries, shows the requester a promised date, and reports the request as done only when the engine confirms the change was made. If your engine cannot provision it, or you have none, Warde routes a task to the right team at the right time.
User access reviews, with evidence
Scheduled user access reviews show a reviewer what people hold. Every decision, and every revoke that follows, is recorded in the evidence pack.
Your identity system stays the system of record. Warde does not take over your role model, your policy engine or your identity warehouse. It does not spot the joiner or the leaver either: your HR feed calls its lifecycle endpoint, and Warde provisions from there.
An agent inherits the access of whoever ran it.
Copilots and MCP clients act with delegated permission. They can do exactly what the person who ran them can do, and nothing stops them using all of it. Every grant a person should have lost three roles ago is now reachable by software acting in their name.
Warde governs human access. That is what an agent borrows when it acts for somebody.
There is no separate agent entitlement to review. The agent uses the user's, and keeping that correct is what this product was already built for.
The agent is the person who ran it
MCP clients and copilots hold delegated permission under OAuth. The agent's ceiling is that person's access, so somebody carrying ten years of accumulated grants hands all of it to something willing to use all of it.
Dormant access stops being dormant
A person uses a fraction of what they hold, which is why over-provisioning has been survivable. An agent can use all of it in a second, and a prompt injection reaches exactly as far as the permissions allow.
Machine and non-human identity is a different product, and Warde does not claim it. What Warde will do is let an assistant use it. An MCP server is on the roadmap, so an assistant can raise a request, read what somebody holds or take a review decision, under the same permissions the person has.
Three screens from the running application.
All of it lives in Employee Center, which your staff already use for laptops and leave. The screens are built for people who have never heard the word entitlement: plain names, one place to ask, and nothing to learn.
Search, request, one approval over the lot.
The form is narrowed to what you are allowed to be given. Access you already hold is marked and cannot be asked for twice. Terms of use are read and accepted on the form. Before anything is raised, the form shows the approver your policy resolved to.
- 1The application asks its own questions first, so the list that follows fits where you work.
- 2Access you already hold is listed and marked, and cannot be asked for a second time.
A user access review a line manager can read.
Reviewers keep or take away access one row at a time or several at once, and hand over any row that was never theirs to judge. Each row shows how the access was granted. Nothing is saved until they choose, and the screen confirms every decision.
Configured to the way your company works.
Guided setup walks your team through the decisions that shape the product: who can ask, and for whom; who approves what; how long access lasts; which engine delivers, and what happens when none does; what counts as high risk; how reviews run; what the emails look like. Every one is a setting on your instance, changed without a developer.
- 1Each step is a decision about your organisation, and the screen shows what the instance already holds for it. Here one administrator holds the role, so nobody else can raise a request yet.
Days for the platform, an afternoon per application.
Your platform team does it, through three wizards. It needs no consultant and no update sets, and changing your mind later needs no developer.
Guided setup, thirteen steps
Grant the roles, connect an engine or choose task fulfilment, bind accounts to people, import what they hold, decide who approves, publish the catalog items and My Access, brand the emails, schedule the reviews. Most of the day is spent on your decisions rather than on clicks.
Onboarding wizard, eight steps
Set the owners, approval policy, expiry and audience. Then one bulk pass gives a plain name, an owner and a risk rating to every entitlement the application brought in.
Approval policy wizard, four steps
Write or change a chain and try it against a real request before anybody has to live with it.
A different approval policy for every kind of access.
Standard access goes to the manager. High-risk access adds the application owner and security. Licensed software adds the licence owner. A bundle is approved once, for everything in it. Each policy is a chain of stages you write in the wizard. Every approver comes from your own data: the requester's manager, the entitlement's owner, a group, a named person, or a field on the application's CMDB record such as who manages it. Conditions read the request line, so a stage can run only for admin accounts or only above a risk rating. If a stage's approver is missing, it falls back to one you name instead of being skipped.
Works with the identity system you own, or with none.
A connector reads what people hold and writes changes back. Every connector is in the price, and most customers need none.
SailPoint Identity Security Cloud
Reads what people hold and writes changes back.
SailPoint IdentityIQ
Reads and writes, and confirms that each change was made.
Microsoft Entra ID Governance
Coming soon.
Saviynt
Coming soon.
It works where you have no engine at all.
Provisioning and deprovisioning are dispatched as tasks to the team that owns the application. Requests, approvals, user access reviews and the evidence pack are the same either way.
What each vendor's ServiceNow application does on your instance.
A tick means the work happens in ServiceNow. A dash usually means the vendor does it well in its own console.
| Warde | SailPoint | Saviynt | Entra | Okta | Omada | |
|---|---|---|---|---|---|---|
| Ask for access in the ServiceNow catalog | yes | yes | yes | yes | partly: the documented integration runs the other way, from Okta into ServiceNow | yes |
| Approve it in ServiceNow | yes | yes | yes | yes | partly: the documented integration runs the other way, from Okta into ServiceNow | yes |
| Your identity engine does the provisioning | yes | yes | yes | yes | yes | yes |
| User access reviews decided in ServiceNow | yes | yes, for Identity Security Cloud: SailPoint documents a certification portal in ServiceNow where certifiers approve, revoke and sign off | no | no | no | no |
| Campaigns defined and scheduled in ServiceNow | yes | their console | their console | their console | their console | their console |
| Approval policies built in ServiceNow | yes | no | no | no | no | no |
| Access bundles curated in ServiceNow | yes | no | no | no | no | no |
| My Access: one page for what you and your team hold, and the reviews waiting on you | yes | partly: the app shows the roles and access profiles a person holds, without a team view or reviews on the same page | not stated | their console | their console | not stated |
| An admin workspace on the instance: what is stuck, what is stale, connector health | yes | not stated | not stated | no | no | no |
| The auditor’s evidence pack, in ServiceNow | yes | no | no | no | no | no |
| Runs with no identity engine at all | yes | no | no | no | no | no |
| Spots the joiner and the leaver for you | not on its own: your own joiner and leaver trigger calls Warde’s lifecycle endpoint, and Warde provisions from there | yes | yes | yes | yes | yes |
Read from each vendor's published documentation in September 2026. For Okta, "partly" means the documented integration runs the other way: a request raised in Okta creates a record in ServiceNow. For SailPoint on the My Access row, it means the app shows what a person holds, without the team view or the reviews waiting. SailPoint's tick on user access reviews is for Identity Security Cloud's Store app, which SailPoint documents as a certification portal where certifiers approve, revoke and sign off. The IdentityIQ integration does not include it. On the last row, Warde does not watch your HR feed. Whichever system already knows somebody has joined or left calls Warde's lifecycle endpoint, and Warde grants or removes the access from there. The full sixty-three-row version, sources attached, is yours if you ask for it.
One price, and you can work it out yourself.
Every feature and every connector is included. Nothing is charged per module, per approver or per campaign. The only thing that moves the price is how many identities Warde governs.
Most customers under 4,200 identities pay exactly this.
An 8,000-person customer pays US$24,500 a year, about US$3 an identity.
A 25,000-person customer pays US$62,000 a year, under US$2.50 an identity.
US$15,000 covers your first 4,200 identities. Each identity above that adds US$2.50 a year, and each one above 15,000 adds US$2.00. Nobody pays more for being one identity over a line.
What that works out to, at any size
| Identities | Subscription | Per identity |
|---|---|---|
| 2,000 | US$15,000 | US$7.50 |
| 5,000 | US$17,000 | US$3.40 |
| 8,000 | US$24,500 | US$3.06 |
| 15,000 | US$42,000 | US$2.80 |
| 25,000 | US$62,000 | US$2.48 |
| 60,000 | US$132,000 | US$2.20 |
An identity is an active, non-service user record, counted by a report the application ships. Service accounts, locked-out users and inactive records are not counted. The count is taken at purchase and again at each renewal, never mid-term, so hiring through the year never produces an invoice. It is not your ServiceNow fulfiller licence count: the price tracks the whole staff base, because that is the population the product governs.
Australian dollar prices come from a published card of their own and are not converted on the day. That card is A$6.00 on the first 3,000 identities, A$4.00 to 15,000 and A$3.00 above, with an A$22,500 minimum.
List prices, sold through the ServiceNow Store. The first three customers get up to 30 percent off. The discount is written into the order form, in return for three things they agree to give: a named case study, a Store review, and a reference call for later prospects.
| Where it comes from | Hours a year | Value |
|---|---|---|
| Service desk time on access requests | 2,100 | US$94,500 |
| Business time: asking, approving, and new starters waiting to start | 1,780 | US$80,000 |
| Access bundles for most joiners and movers: 3,300 fewer approvals | 890 | US$40,000 |
| High-risk access reviews run as campaigns for each application owner | 250 | US$11,000 |
| Less the subscription | - | −US$24,500 |
| Net a year | 5,020 | US$201,000 |
Service desk time alone pays for the subscription in under four months. If you build roles by hand today, as catalog items or order guides, building them as bundles in Warde saves about US$28,500 a year more.
How each line is worked out
| Line | Basis, at US$45 an hour |
|---|---|
| Service desk | 7,000 access requests a year, 35 percent of 21,000 requested items, at 40 minutes each. Connector fulfilment and named tasks take out 45 percent. |
| Business time | People asking: 12 minutes a request, a third removed (470 hours). Approvers: 2 minutes on each approval read, half removed (90). Managers: 40 minutes deciding what each joiner or mover should hold, halved for the half with a bundle (270). New starters: half a day blocked by missing access, a quarter of it back (950). |
| Access bundles | Owners sign off each bundle once, and each request then needs only the line manager. With four in five joiners and movers on bundles instead of half: 3,300 fewer approvals, 2,000 fewer requests and less waiting, less 140 hours a year to build and keep 80 bundles. On the NIST study's measured wait for roles it comes to about 2,900 hours. |
| High-risk reviews | 30 applications reviewed every quarter, 25 people each. About three hours per application by hand: pulling the list, chasing the owner, raising removals and filing the evidence. About 45 minutes as a campaign, most of it the owner deciding. |
| Subscription | 8,000 identities, every feature and connector included. |
Every business-side figure is an assumption, set low on purpose. Replace each with your own before taking this to a budget holder. The quickest start is a report on sc_req_item over the last twelve months, grouped by catalog item, with the access items marked.
Sources: Fixify 2026 IT Help Desk Benchmark Report · Enterprise Strategy Group, now Omdia, on the six-day wait for a new hire's access · O'Connor and Loomis, 2010 Economic Analysis of Role-Based Access Control, RTI International for NIST · Ponemon Institute for GuidePoint Security, 2025 · Zluri, a governance vendor, on manual and automated reviews · Serval · HDI · Gartner IT Key Metrics Data.
Nothing to host. Nothing leaves your instance.
No vendor tenant, no middleware, no copy of your people or their access anywhere else. Outbound only, from your instance, on credentials you hold. The facts a platform review asks for are below.
| Question | Answer |
|---|---|
| Where does it run | As a scoped application on your instance, installed from the ServiceNow Store as one versioned release. No servers, containers or agents. The people who already run your instance run this. |
| What does it store | 26 tables of its own, all in its scope, plus six import set staging tables the sync uses. Tables in a certified Store application do not come out of your custom table allocation. Your request, task, user and group records are read, never altered. Whatever your team has customised over the years, there is nothing of ours in it to conflict with. |
| How does it connect | Outbound REST from your instance to your identity system, on credentials held in your instance. No vendor service calls in. Your HR feed can call one lifecycle endpoint on your instance to say who has joined or left. |
| Where do staff use it | Employee Center: three catalog items (Request access, Access bundles, Remove access) and one portal page, My Access. Nothing new to log in to. |
| Where do admins use it | A workspace that says what is stuck and what is stale, and three wizards: guided setup, application onboarding, approval policy. Changing who approves what needs no developer. |
| What roles does it add | Three application roles, granted in guided setup. Everything else runs under the platform's own access controls. |
| What about email | Your existing service catalog notifications keep working as they are. Warde sends only a handful of its own, triggered by events on the request and the review, with your branding if you want it. One property hands them to your own notification stack instead. |
| Does it need AI | No. Nothing in the product depends on an AI licence, and it behaves the same on an instance that has never had one. |
| What does an auditor get | A full history of every request, approval, delivery, removal and review decision, insert-only with no update and no delete for anybody, kept seven years by default. User access review evidence packs that freeze the campaign as it was launched and keep their own copy of every person, account and entitlement. Each revoke in them is confirmed back from the engine. |
The most common IT weakness a public company discloses is somebody's access.
Rights that were never appropriate, and leavers who kept theirs. KPMG counted 238 companies disclosing a material weakness in fiscal 2025. Within the IT general controls theme, that is what most of them were about.
An auditor asks whether the list under review was complete.
A spreadsheet cannot answer that. Months later, nobody can show which query produced the export, on what date, or that nothing was dropped between the export and the sign-off. Warde's evidence pack can.
The pack reports the campaign as it was launched
A campaign snapshots its scope, its reviewers and its rules the moment it launches, and the export reads the snapshot. An edit made afterwards cannot change the record of what was reviewed.
A rename does not rewrite the evidence
Every line keeps its own copy of the person, the account, the entitlement, how the access was granted and when. An audit row that resolves to "(deleted)" is not audit evidence.
Taken away, and confirmed back
A revoke records the engine that ran it, the engine's own reference, and the stamp confirming it was carried out. Items the source system stopped including partway through the campaign stay in the pack, marked as withdrawn.
The four controls an auditor tests, and where Warde stands
| Control | What is asked for | Where Warde stands |
|---|---|---|
| Provisioning | Was it authorised before it was granted, by somebody with the standing to authorise it | The chain resolves to named approvers before the request is raised, and every decision is a row carrying a person, a time and the policy that put them there |
| Deprovisioning | Was a leaver's access removed inside the window, and can you show that it went | Removals and review revocations run the same approval and fulfilment path and are confirmed back rather than assumed. Warde does not spot the leaver: your joiner and leaver feed calls the endpoint. Access past its expiry date is removed by a nightly pass, with warnings to the holder and their manager first |
| Periodic review | Did somebody independent confirm the access is still appropriate, on a cadence, and can you prove what was in front of them | Scheduled user access review campaigns, reviewer strategies that fall through to the holder's manager and then to a mandatory backstop, delegation, and the evidence pack |
| Separation of duties | Are conflicting combinations stopped on the way in, or found and cleared | Verdicts on the form and again on the line before approval, enforced per entitlement as block, warn or off. The ruleset stays in your engine, so an application with no engine behind it gets no check |
Warde is not a GRC platform. It keeps no control library and maps nothing to frameworks. What it produces is the evidence for one family of controls, in a shape an auditor can test.
US filers
Authorised provisioning, timely removal, periodic review, separation of duties.
Card data
Requirement 7.2.4: review accounts and access at least once every six months.
Annex A 5.18
Access rights reviewed at planned intervals by the owner, and documented.
Australia
Access control and third-party assessment, sized to the threat.
Europe
ICT risk management, including the review of access rights.
Quarterly reviews satisfy every one of them, and quarterly is what a filer needs anyway.
Built and running, waiting on Store certification.
What is built and what is not are both named, so you can decide whether the gaps matter to you.
Working today
On a developer instance now, covered by 56 automated tests- ✓Request access, with the duplicates, conflicts, expiry rules and approval chain settled on the form
- ✓Access bundles, asked for whole, given back whole, and curated by the people who own the access
- ✓Remove access, down the same path as a grant
- ✓Approval policies, as many stages as the access deserves, written in a wizard
- ✓Fulfilment that retries, promises a date, and raises a task when it cannot finish
- ✓User access reviews, from the campaign to the evidence pack, with delegation in between
- ✓My Access, what you hold, what your team holds, and what is waiting on you
- ✓Administration, three wizards and a workspace that says what is stuck and what is stale
- ✓A regular read of your identity system, so the record of what people hold stays current
- ✓Joiner, mover and leaver provisioning, as an endpoint your HR system calls. Spotting the joiner stays with you
- ✓Birthright bundles, granted by policy with no approval when your joiner feed names them
- ✓Expiry, with access past its date removed by a nightly pass that warns the holder and their manager first
Coming soon
Named so you can decide whether it matters- ○Entra ID Governance connector
- ○Birthright by rule. Warde choosing the bundle from department, location or job, rather than your feed naming it
- ○Account creation. Somebody with no account on the target system yet is reported, not created
- ○Reporting on orphan accounts, dormant access, and who has what
- ○An MCP server, so an assistant can raise a request, read what somebody holds or take a review decision, under the same permissions the person has
- ○Saviynt connector
If what you need is on neither list, ask for it.
Releases are short and the people who ask set the order, so a feature goes from a call to a release without waiting on anybody else's roadmap. Bring the request your current tool will not handle, or the report your auditor keeps asking for. If it belongs in an access request product, it gets built.
Not everything will. Some of what you need is your identity engine's job, and you will hear that on the call rather than after the purchase order.
Bring the access request you hate most.
Forty-five minutes on a live instance, with no slides. We will show you what replaces it, what it costs, and what the product still cannot do.
- [email protected]Or book a walkthrough by email
- Built by
- Stephen HarlandMelbourne, Australia
- Availability
- ServiceNow StoreSold and updated through the Store, as one versioned release
- Launch offer
- Up to 30 percent offFirst three customers, in return for a case study, a Store review and a reference call