Your governance team writes rules. Your authorization team enforces rules. They speak different languages, track different metrics, and sleep differently at night when things break. This is the hidden cost of treating identity governance and runtime authorization as separate domains.
The Problem: Two Systems, Two Languages, Two Truths
In traditional architecture, governance and authorization operate in parallel universes. Your GRC platform defines what should happen: contractors can't get admin rights, finance staff can't approve their own purchases, interns stay in limited zones. Sound policies. Clear rules.
Meanwhile, your authorization engine—the policy decision point—makes runtime calls using a completely different attribute model. Different rule syntax. Different audit trail. Different truth. When the quarterly compliance review arrives, you realize the governance engine and the authorization engine aren't even speaking about the same things.
The Gap: Governance rules live in one system. Authorization rules live in another. When they diverge—and they always do—you have a choice: trust the governance audit, trust the authorization audit, or remediate manually. Annually.
The EmpowerNow Approach: Unified Policy, Unified Evidence
What if your governance rules and your authorization policies were the same thing? Not integrated. Not synchronized. The same. IGA governance rules ARE authorization policies. They define both what provisioning decisions should make (the offer layer) and what runtime decisions should enforce (the PDP layer). One policy family. One audit trail. One source of truth.
Four Policy Families That Drive Everything
Guardrails: Preventing Dangerous Paths
Negative policies that block dangerous provisioning combinations. Contractors never get admin. Interns never access finance systems. Externals always receive guest-level tokens. Evaluated at both offer time and runtime.
Rule: Contractor Admin Block
IF user.type = "Contractor"
AND role = "Admin"
THEN DENY
Reason: Contractors cannot hold administrative privileges
Audit: Block time, who attempted, remediation trailSeparation of Duties: Preventing Conflicts
Policies that prevent conflicting role combinations. SoD rules cover four families: Financial (can't approve own expense), Security (can't manage own access), HR+Payroll (can't process own compensation), Procurement+Vendor (can't approve own vendor payments). Evaluated every time a role assignment happens—and every time the user attempts a transaction.
Rule: Financial SoD - Approver Segregation
IF user has role "AP_Processor"
AND user attempts role "AP_Approver"
THEN DENY
Reason: Same person cannot process and approve payments
Evaluation: At provisioning AND at request timeBirthright: What Everyone Gets
Positive policies that define baseline access for specific populations. New hires on Day 1 get employee portal access plus role-specific systems. Transfers between departments trigger automatic revocation of old team permissions and automatic provisioning of new ones. Contractors get limited birthright (no internal comms, no financial data). Explicit paths and explicit deny paths coexist.
Rule: New Hire Birthright
IF user.type = "Employee"
AND user.tenure_days < 1
THEN GRANT ["EmployeePortal", "SSO", "Email"]
IF user.department = "Finance"
THEN GRANT ["GLAccess", "VendorMgmt"]
IF user.department NOT IN ["Finance", "Legal"]
THEN DENY "ExecutiveReporting"Temporal Access: Time-Bound Permissions
Policies that automatically expire access on schedule. Contract end dates. Emergency windows (elevated access granted for 4 hours, then automatically revoked). Business hours gates (3am access is unusual, maybe invalid). Tenure limits (if someone stays 5+ years in a low-change role, trigger review). No batch job. No manual intervention. No stale permissions. Evaluated at decision time.
Rule: Contractor Access Expiration
IF user.type = "Contractor"
AND current_date >= user.contract_end_date
THEN DENY all access
Revoke active sessions immediately
Rule: Emergency Elevated Access Window
IF emergency_approved = true
AND current_time < (grant_time + 4 hours)
THEN GRANT elevated_roles
IF current_time >= (grant_time + 4 hours)
THEN DENY (auto-revoke)PDP Decides, Fulfillment Executes
A critical distinction: the Policy Decision Point (PDP) answers the governance question: "Should this access be granted?" It evaluates the rules, applies the policy, and returns a decision. That's the governance layer.
Fulfillment—the actual provisioning and deprovisioning—answers the operational question: "How do we safely execute this decision?" It handles obligations (must be audited, must notify manager, must enforce MFA), error handling, and rollback.
The PDP decision and the fulfillment execution are coupled by policy, not by implementation. Same rule. Same audit trail. Different responsibilities. This is what unified governance actually means.
What Changes: Unified Audit Trail and Evidence
Traditional audit: You have two separate logs. GRC says "we granted this access on this date under this policy." Authorization says "we allowed this request on that date under that rule." Quarterly review: You reconcile them manually. Inconsistencies surface. Remediation is manual.
EmpowerNow unified audit: One engine answers both questions. "Who should have access?" (governance) and "Who actually has access?" (authorization) are answered from the same policy evaluation. Same timestamp. Same rule. Same context attributes. When an auditor asks "why does this person have this access," you pull one record.
Practical Example: Contractor Access Lifecycle
Carol joins as a contractor on Day 1 for a 6-month engagement.
Day 1: Onboarding
Carol's record enters the system with type="Contractor" and contract_end_date="2026-10-03". The Birthright policy fires: Carol receives SSO, email, and project collaboration tools. The Guardrail policy fires: Carol is blocked from admin access. No manual review. No configuration. The policies evaluate and the decision flows to fulfillment.
Day 60: Runtime Enforcement
Carol attempts to access the financial reporting system at 11pm. The authorization decision fires: Is Carol allowed? Check the Guardrail (no). Check Temporal Access (within contract window, check). Check Birthright (not listed for Finance). Result: DENY. No special ticket. No manual check. The policy evaluated in real time. Carol sees a friendly message and tries another system. Audit trail logs the decision, the policy, and the reason.
Day 180: Automatic Revocation
October 3rd arrives. The Temporal Access policy triggers: contract_end_date has passed. Carol's active sessions are terminated. All access is revoked. No manual offboarding. No batch job. No stale permissions. The policy evaluation happens at request time and Carol is locked out. Her manager receives a notification. Audit trail shows automatic revocation with policy reference.
From Silos to Unified Control
When IGA governance rules are your authorization policies, the gap collapses. You don't synchronize two systems. You run one system with unified logic, unified audit, unified evidence. What should happen and what actually happens are answered by the same engine, the same policies, the same audit trail.
That's not governance and authorization sitting next to each other. That's governance and authorization becoming the same thing.
IGA governance runs on EmpowerNow's unified PDP. Explore IGA capabilities →