ITSM
Operates joiner/mover/leaver, request, approval, provisioning, change, incident, remediation, vendor, and lifecycle work.
Explore ITSM →ThreatKrusher Pillar 04 · Identity and controlled authority
Give the right identity the minimum necessary access for the approved purpose.
ThreatKrusher Access governs human, administrator, contractor, service, workload, application, and AI-agent identities across authentication, authorization, privilege, lifecycle, review, exception, and revocation.
The access problem
Authentication answers “who”; governance must also answer “why, where, what, and for how long.”
Access risk accumulates when identity sources, approvals, roles, privilege, service accounts, external users, applications, and offboarding are managed as separate technical tasks.
- Accounts exist without a current owner, purpose, sponsor, or expiry.
- Role changes add new access without removing obsolete rights.
- Administrative privilege is permanent, shared, or used for routine work.
- Service and workload identities use unmanaged secrets or excessive permissions.
- External parties retain access after the business relationship changes.
- Reviews list entitlements without enough context for an accountable decision.
Scope boundary
Define which identities, resources, decisions, and systems are governed.
Included when contracted
- Identity source and account inventory
- Joiner, mover, leaver, contractor, and guest workflows
- Authentication and conditional-access configuration
- Role, authorization, privilege, and delegated-administration design
- Service, application, workload, and agent identity governance
- Access reviews, exceptions, monitoring, evidence, and revocation
Not implied
- Coverage of every application, tenant, device, identity, or entitlement
- Zero risk because MFA or single sign-on is deployed
- Automatic approval of business need or segregation of duties
- Elimination of phishing, credential theft, session abuse, or insider risk
- Privileged-access tooling or passwordless methods without explicit scope
- Authority to approve access on the client's behalf
Client assumptions
- Authoritative worker, role, status, sponsor, and ownership facts
- Named access, data, system, and business approvers
- Approved role models, separation rules, and prohibited combinations
- Timely notice of hires, changes, termination, vendors, and leave
- Risk decisions for exceptions, legacy systems, and third parties
- Participation in reviews, remediation, testing, and emergency access
Access governance system
Six disciplines govern identity from source to revocation.
Identity source
Establish authoritative context
Person or system, owner, sponsor, role, status, purpose, organization, sensitivity, and lifecycle source.
Authentication
Verify the actor
Approved factors, device and location context, session conditions, recovery, enrollment, exceptions, and signals.
Authorization
Limit permitted action
Role, resource, entitlement, data, operation, condition, environment, business need, approval, and duration.
Privilege
Separate elevated authority
Named administrators, dedicated identities, just-in-time or time-bound access, approvals, monitoring, emergency use, and review.
Non-human identity
Govern services and agents
Owner, purpose, workload, secret or credential, permission, rotation, dependency, activity, expiry, and revocation.
Review & response
Revalidate continuously
Access certification, exception, stale-account action, risky-event response, remediation, revocation, evidence, and next review.
People · process · system
Access is a business decision implemented through technical controls.
Identity and access lifecycle
Every grant needs a source, approver, purpose, duration, and exit.
01
Request
Capture identity, sponsor, resource, business purpose, role, data, entitlement, duration, and urgency.
02
Verify
Confirm identity, worker or service status, authoritative facts, eligibility, conflicts, and request integrity.
03
Authorize
Obtain accountable owner approval, apply role and separation rules, and document exception or risk decisions.
04
Provision
Create or update the identity, factors, groups, roles, privileges, conditions, expiry, and supporting records.
05
Review
Revalidate status, need, use, ownership, privilege, risk, exceptions, inactivity, and anomalous conditions.
06
Revoke
Remove access, terminate sessions, rotate secrets, recover assets, preserve records, validate closure, and address dependencies.
Evidence produced
Make each access decision reconstructable.
Identity
Identity record
Type, source, owner, sponsor, role, status, purpose, systems, start, change, end, and review dates.
Authority
Access decision
Request, business need, resource, entitlement, approver, rules, conflicts, exception, duration, and conditions.
Operation
Provisioning record
Account, factors, groups, roles, privilege, configuration, administrator, system result, validation, and timestamp.
Review
Access review
Population, scope, reviewer, decision, stale or risky access, remediation, revocation, residual exception, and next review.
Responsibility boundary
Separate business authority, technical administration, and platform responsibility.
eTrepid performs when contracted
- Identity and access architecture support
- Approved configuration and administration
- Lifecycle, review, exception, and remediation workflows
- Monitoring, evidence, reporting, and technical escalation
- Vendor and platform coordination within authority
The client retains
- Accurate worker, vendor, role, ownership, and status facts
- Business need and resource-owner approval
- Policy, risk appetite, exception, and separation decisions
- Timely joiner/mover/leaver and emergency notifications
- Legal, employment, privacy, and material business authority
Platforms and third parties retain
- Native security architecture and service availability
- Supported authentication, authorization, logging, and API behavior
- Vendor-side accounts, roles, data, and administrative controls
- Customer/provider shared-responsibility obligations
- Specialized privileged, secrets, or identity-governance functions
Critical dependencies
Access depends on controlled service work, security signals, and governance.
Trust
Monitors authentication, risky identity conditions, privilege activity, anomalies, incidents, and validation evidence.
Explore Trust →Comply
Connects identity obligations, policies, control owners, review requirements, exceptions, evidence, and risk decisions.
Explore Comply →Identity proof gate
Verify platform coverage and control operation before publishing claims.
Public proof should use approved, redacted joiner/mover/leaver records, MFA or conditional-access evidence, privileged-access records, service-account governance, access reviews, revocation validation, or metrics with defined scope and limitations.
Publication hold
No current supported-platform list, MFA coverage, privileged-access capability, lifecycle target, access-review result, service-account metric, or client outcome is approved for this page. Reconcile service schedules, tenant configuration, platform records, workflow definitions, measurement sources, and delivery ownership first.
Common questions
Clarify identity and authority before changing access.
Does MFA make our access secure?
MFA can materially strengthen authentication, but access governance also depends on identity source, enrollment and recovery, factor strength, session controls, authorization, privilege, device and location context, monitoring, exceptions, and timely revocation.
Can eTrepid approve employee or contractor access?
eTrepid can operate approved workflows and perform technical administration within scope. The client’s accountable resource, data, system, or business owner must authorize business need and risk unless a documented delegation expressly says otherwise.
Are service accounts and AI agents governed like people?
They require the same core principles—identity, owner, purpose, least privilege, authorization, monitoring, review, and revocation—but their credentials, workload context, rotation, dependencies, actions, and failure modes need specialized controls.
Does zero trust mean nobody is trusted?
No. It means access decisions should not rely solely on network location or a one-time implicit trust assumption. Identity, device, context, resource, policy, risk, and session conditions are evaluated according to the implemented architecture.
Identity and access briefing
Start with the identity sources, critical resources, approval authority, and lifecycle gap.
Provide only non-sensitive context about identity platforms, user and non-human identity types, applications, current ownership, business trigger, recurring pain, and desired operating model.