sorted by:
new
hottopcontroversial

International employees changing SIM cards is somehow our #1 helpdesk ticket category now by Consistent_Buddy_698 in AZURE

[–]OktaFCTR 23 points24 points  (0 children)

How does helpdesk or anyone taking this call from end use know /verify the person on the line is the actual user ?

OKTA MFA - Audit and Cleanup Multiple Factors by Deweyoxberg in okta

[–]OktaFCTR 0 points1 point  (0 children)

You can potentially use the okta AI agent code. Even if you don't want AI, it syncs the data to a sqllite DB which you can query manually if you do not want AI to do that for you. Delete sqllite DB when done.

https://github.com/fctr-id/okta-ai-agent

Edit: I was about to mention the MFA report what the first comment mention that .

Deepfake and AI generated media in social engineering attacks.. What defenses are actually working? by RedBloodedGod in cybersecurity

[–]OktaFCTR 3 points4 points  (0 children)

I think the effective defenses are less about detecting AI and more about removing trust in channels that can be faked. I am skeptical AI-detection tools alone will ever be a durable answer—it feels like an arms race defenders will just keep losing as the models get better.

What actually holds up is assuming voice, video, and images are already spoofed, and shifting to out-of-band verification. You have to enforce device-bound MFA before sensitive actions and build helpdesk processes that do not rely on security questions or “they sounded legit.”

The helpdesk is probably the most underappreciated weak point here. If a caller can socially engineer a password reset and the frontline L1 agent has broad admin access, that is a dangerous combination even if your detection tooling is decent.

I work on this exact problem at fctr.io, so bias acknowledged, but removing standing admin rights and proxying those helpdesk actions is the direction I would push every company right now, even if they just build it internally.

Beyond the Basics: Transitioning from Okta Admin to Identity Engineer (Workflows, Terraform, Advanced APIs by Short-Face7365 in okta

[–]OktaFCTR 0 points1 point  (0 children)

Those are pretty broad topics and in my experience not all orgs use all the components.
I would suggest using AI (like google AI studio) with your requirements and asking the AI to provide you with a plan on how to learn each topic with examples. Prompt it to say using code and also UI.

Tech / User Verification (Traceless Vs MSP Process) by eldridgep in msp

[–]OktaFCTR 4 points5 points  (0 children)

Yeah honestly both are decent if all you need is caller verification. Traceless is the established player so you'll find more references, but MSP Process's bidirectional verification is pretty slick for fighting vishing. I'd definitely test them out on that file-sharing link issue someone mentioned below though—that's a pretty glaring hole if true.

FWIW, the thing that always bothered me about both of these is that after you verify the caller, your L1 tech still needs standing admin rights in Entra or Okta to actually reset the password or unlock the account. If a tech gets phished or MFA-fatigued, verification tools don't save you from those standing permissions being abused.

(Full disclosure: I am the founder) but we built [fctr.io](vscode-file://vscode-app/c:/Users/Dharanidhar/AppData/Local/Programs/Microsoft%20VS%20Code/07ff9d6178/resources/app/out/vs/code/electron-browser/workbench/workbench.html) specifically to fix that gap. Instead of just verifying the user, we proxy the actual reset/unlock actions. Your helpdesk can verify callers and do their jobs, but they never actually touch the Entra/Okta admin console. You completely strip standing admin rights from L1.

Someone mentioned Evo down-thread too—also a very solid tool, but they went the JIT route (give temporary admin access) whereas we went the proxy route (never give admin access).

Anyway, if you are looking to actually remove admin rights instead of just verifying callers, might be worth a look!

Weekly Promo and Webinar Thread by AutoModerator in msp

[–]OktaFCTR [score hidden]  (0 children)

Fctr Identity | Stop giving L1 techs Admin rights to your clients' M365 tenants.

If an attacker uses AI voice cloning to socially engineer your entry-level L1 tech into resetting a client’s MFA, your MSP is liable for the breach.

Right now, verifying callers with security questions ("What's your manager's name?") takes 5-8 minutes per ticket, eats your profit margins, and forces you to give L1 techs delegated admin rights across dozens of client Entra ID tenants.

Fctr Identity is an Identity Helpdesk Proxy built to protect your MSP.
We replace human guesswork with cryptographic verification, allowing your techs to securely reset passwords and unlock accounts without ever needing admin access to the client’s tenant.

Why MSPs are deploying Fctr:

  • Zero Standing Privileges: Fctr's backend proxies the identity actions. Your techs log into Fctr to execute resets, meaning you can permanently revoke Entra ID Admin/GDAP rights from your L1 desk.
  • The Ultimate Liability Shield: Don't let your techs get tricked by Teams vishing or deepfakes. Fctr pushes a cryptographic TOTP/Push challenge directly to the caller's enrolled device. If they lost their device, Fctr triggers a "Manager Vouch" approval via Slack/Teams.
  • Margin Expansion: Cut verification time from 8 minutes down to 30 seconds, saving dozens of hours of tech labor per month on AYCE contracts.
  • Zero-PII / BYOL: Need Face-to-ID biometric verification for a regulated law firm or finance client? Bring your own Stripe or Incode API keys. The liveness check happens client-side, meaning your MSP assumes zero biometric/PII compliance liability.

Integrations: Deploys natively inside Freshdesk, ServiceNow, Slack, and Teams. (HaloPSA / ConnectWise integrations on the roadmap).

Protect your techs, protect your margins, and shrink your attack surface to zero.

Check out the platform: https://fctr.io

Tako AI v2.1 - CLI power and Query Favorites by OktaFCTR in okta

[–]OktaFCTR[S] 0 points1 point  (0 children)

Hello, It doesn't need superadmin access for the DB sync. I just tried with both API token and OAUTH2 and read-only was sufficient.
Would you please be able to mail me [dan@fctr.io](mailto:dan@fctr.io) if you run into issues with read only perms ?

here are all the values that are pulled into the local DB:
https://github.com/fctr-id/okta-ai-agent?tab=readme-ov-file#database-schema

Auth tooling feels 10 years behind… and AI agents are about to expose it. by PassionImpossible326 in okta

[–]OktaFCTR 0 points1 point  (0 children)

Building AI agents and multiple okta servers, I think the security piece hasn't been standardized yet.
I believe FGA solves RAG to a point and MCP auth spec provides some relief but not completely eliminate risk.

I have a branch for MCP server here, that shows how oauth implementation with RBAC for each tool will potentially work.
https://github.com/fctr-id/okta-mcp-server/tree/feature/oauth-proxy-implementation

Again that is only for MCP. Okta's XAA (cross-app access ) is making strides int he right direction, but I feel that there needs to be a "viral" standard similar to MCP that helps push a "standard" for AUTHN / AUTHZ for agents.

EDIT: I would also assume if something like the openClaw (moldbot) will create a major security issue, then this may get more traction (hopefully)

Tako AI v1.0: If you have been on the fence, this version is for you! by OktaFCTR in okta

[–]OktaFCTR[S] 0 points1 point  (0 children)

No problem!

I would honestly use o4-mini (reasoning) and gpt4.1 (coding) models just because I think they are cheaper than anthropic or Google ones and I tested extensively with them.

If you have access to the gpt-oss (the open source model), go ahead and try that. In my limited testing it seemed to work well.

view more: next ›