با توجه به خطر شنود و دستکاری داده‌های امنیتی در هنگام انتقال بین مؤلفه‌های داخلی سیستم (مانند بین وب‌سرور و سرور پایگاه داده)، از کانال‌های رمزنگاری‌شده (TLS 1.3 با احراز هویت دوطرفه) استفاده می‌شود. همچنین، داده‌های حساس هرگز به صورت متن آشکار در حافظه مشترک (Shared Memory) یا صف‌های پیام قرار نمی‌گیرند.
به منظور جلوگیری از حملات تزریق و تفسیر نادرست، سیستم هنگام تبادل داده با موجودیت‌های خارجی (مانند سرویس‌های احراز هویت مرکزی یا ماژول‌های سخت‌افزاری) از یک فرمت داده‌ای استاندارد و توافق‌شده (مانند JSON Web Token با امضا) استفاده می‌کند. هرگونه داده ورودی که از نظر ساختار یا امضا نامعتبر باشد، رد شده و رویداد آن در لاگ ثبت می‌شود.
به منظور جلوگیری از حملات تکرار و جعل زمان، سیستم از یک منبع زمان دقیق و قابل اعتماد (NTP با احراز هویت و رمزنگاری) برای تولید مهرهای زمانی رویدادهای ممیزی و توکن‌های احراز هویت استفاده می‌کند. زمان تمام مؤلفه‌های سیستم به صورت خودکار با یک سرور مرجع همگام‌سازی شده و اختلاف زمانی بیش از ۵ ثانیه باعث قطع سرویس تا رفع مشکل می‌شود.
به منظور انعطاف‌پذیری در پیکربندی امنیتی، سیستم این امکان را به مدیر امنیت می‌دهد که مشخصه‌های امنیتی (مانند سطوح دسترسی، برچسب‌های محرمانگی و نقش‌ها) را ایجاد، اصلاح یا حذف کند. هرگونه تغییر در این مشخصه‌ها بلافاصله در تمامی نشست‌های فعال اعمال می‌شود (بدون نیاز به ورود مجدد کاربران) اما تغییرات در یک حافظه با قابلیت بازگشت به نسخه قبلی ذخیره می‌گردد.
با توجه به حساسیت داده‌های امنیتی، مدیر امنیت مجاز به مدیریت داده‌های مرتبط با امنیت مانند لیست سیاه آی‌پی‌ها، گواهی‌های دیجیتال، کلیدهای رمزنگاری و سیاست‌های کنترل دسترسی است. تمام این داده‌ها به صورت رمزنگاری‌شده ذخیره شده و عملیات مدیریتی از طریق یک پورتال اختصاصی با احراز هویت چندعاملی انجام می‌شود. تغییرات در این داده‌ها به صورت خودکار در کل خوشه همگام‌سازی می‌گردد.
به منظور پوشش تمام جنبه‌های مدیریت امنیتی، مجموعه کارکردهای مدیریتی الزمی در سیستم شامل موارد زیر است: مدیریت حساب‌های کاربری، تنظیم سیاست رمز عبور، پیکربندی قفل حساب پس از تلاش ناموفق، تنظیم زمان‌خوردگی نشست، فعال‌سازی/غیرفعال‌سازی ممیزی، مدیریت گواهی‌های TLS، و بازیابی نسخه پشتیبان امنیتی. تمام این کارکردها مستند بوده و دسترسی به آن‌ها با اصل تفکیک وظایف (Separation of Duties) محدود شده است.
به منظور اعمال اصل حداقل امتیاز، سیستم از دو نقش امنیتی متمایز پشتیبانی می‌کند: «مدیر امنیت» (Security Administrator) که دارای تمام مجوزهای مدیریت امنیتی است و «بازبین امنیت» (Security Auditor) که فقط مجاز به مشاهده لاگ‌ها و گزارش‌های ممیزی می‌باشد. این نقش‌ها غیرقابل تغییر توسط کاربران عادی بوده و انتساب کاربران به نقش‌ها تنها از طریق فرآیند تأیید دو مرحله‌ای امکان‌پذیر است.
به منظور جلوگیری از تمرکز بیش از حد اختیارات، سیستم توانایی تشخیص و جلوگیری از انتساب همزمان یک کاربر به نقش‌های متضاد (مانند مدیر امنیت و بازبین امنیت) را دارد. جداسازی وظایف (SoD) در سطح سیاست‌های امنیتی اعمال شده و هرگونه نقض احتمالی قبل از اجرا مسدود می‌گردد. این اقدام از سوءاستفاده داخلی جلوگیری می‌کند.
پس از احراز هویت موفق، هویت یکتای کاربر (شناسه داخلی کاربر) به صورت امن به نشست (Session) و به تمام زمینه‌های دسترسی (مانند نقش‌ها و مجوزها) متصل می‌شود. این اتصال در طول عمر نشست قابل تغییر نبوده و هرگونه تلاش برای تغییر آن (از طریق دستکاری کوکی یا درخواست) باعث خاتمه نشست و لاگ یک رویداد امنیتی می‌گردد. برای هر درخواست بعدی، سیستم ابتدا صحت این اتصال را با مقایسه یک توکن داخلی احراز می‌کند. این مکانیزم از جعل هویت و افزایش امتیاز درون نشست (In-session privilege escalation) جلوگیری می‌کند.
به منظور حفظ یکپارچگی مجوزها در طول نشست، سیستم تضمین می‌کند که مشخصه‌های امنیتی منسوب به کاربر در طول مدت یک نشست قابل تغییر نیستند، مگر از طریق فرآیندهای امن از پیش تعریف‌شده (مانند درخواست ارتقای نقش با تأیید دو مرحله‌ای). هرگونه تلاش مستقیم برای تغییر این مشخصه‌ها (از طریق دستکاری درخواست) موجب خاتمه فوری نشست و قفل موقت حساب کاربری می‌شود.
به منظور تفکیک وظایف امنیتی، کارکردهای مدیریتی سیستم (مانند فعال/غیرفعال کردن ممیزی، تغییر سیاست‌های رمز عبور، مدیریت کاربران و پیکربندی امنیتی) تنها توسط نقش «مدیر امنیت» قابل انجام است. تمام عملیات مدیریتی در یک لاگ ممیزی جداگانه ثبت شده و نیاز به احراز هویت مجدد (حداقل با یکی از روش‌های قوی) دارند. هیچ کاربر عادی و حتی مدیر سیستم معمولی به این کارکردها دسترسی ندارد.
برای تضمین اینکه هیچ عملیات حساسی بدون اثبات هویت انجام نشود، دسترسی به تمامی عملکردهای سیستم به جز صفحه اصلی اطلاعات عمومی و صفحه ورود منوط به احراز هویت موفق شده است. حتی نقاط پایانی API که به نظر عمومی می‌آیند (مانند وضعیت سرور) نیز با یک توکن موقت محدود می‌شوند. این الزام هم در سطح مسیریابی (Routing) و هم در سطح منطق برنامه اعمال می‌گردد تا هیچ دور زدنی امکان‌پذیر نباشد. در صورت تلاش برای دسترسی به منبعی بدون احراز هویت، پاسخ HTTP 401 (Unauthorized) برگردانده می‌شود.
برای افزایش امنیت احراز هویت به ویژه برای کاربران با دسترسی بالا، سیستم از چندین روش احراز هویت پشتیبانی می‌کند. این روش‌ها عبارتند از: ۱) رمز عبور قوی (با سیاست ذکر شده)، ۲) احراز هویت دو مرحله‌ای مبتنی بر TOTP (برنامه‌هایی مانند Google Authenticator)، ۳) کلید سخت‌افزاری FIDO2 (WebAuthn)، و ۴) احراز هویت مبتنی بر بیومتریک (فقط در دستگاه‌های پشتیبانی‌کننده). کاربران می‌توانند بسته به سطح ریسک، روش مناسب را انتخاب کنند، اما برای نقش‌های حساس (مدیر، ممیز) استفاده از دو روش (Multi-Factor) اجباری است.
اگرچه کاربران می‌توانند از میان روش‌های پشتیبانی‌شده انتخاب کنند، اما این انتخاب تحت کنترل سیاست‌های امنیتی سیستم بوده و کاربر اجازه استفاده از روش‌های ضعیف‌تر از سطح مورد نیاز را ندارد. برای مثال، اگر کاربر بخواهد از یک رمز عبور ساده استفاده کند، سیستم آن را رد کرده و روش قوی‌تر (مثلاً 2FA) را اجباری می‌کند. همچنین، برای دسترسی به منابع خاص (مانند پنل مدیریت سیستم)، تنها روش‌های مقاوم در برابر فیشینگ (مانند WebAuthn) قابل قبول هستند. سیستم به طور مداوم پروفایل ریسک کاربر را ارزیابی کرده و در صورت لزوم روش احراز هویت را به سطح بالاتری ارتقا می‌دهد.
پس از احراز هویت موفق، مشخصه‌های امنیتی کاربر (نقش، مجوزها و برچسب‌های امنیتی) به شیوه‌ای امن به نشست جاری متصل می‌شوند. این اتصال به صورت رمزنگاری‌شده در سمت سرور نگهداری شده و هر درخواست بعدی با مرجع این مشخصه‌ها احراز می‌گردد. در صورت فوت یا خروج کاربر، این انقیاد بلافاصله فسخ می‌شود.
پس از عبور از آستانه خطاهای ورود (۵ تلاش ناموفق)، حساب کاربری به طور خودکار قفل می‌شود. مدت قفل ۱۵ دقیقه در نظر گرفته شده است؛ پس از آن کاربر می‌تواند دوباره تلاش کند (اما آستانه تلاش‌ها بازنشانی می‌شود). در موارد حساس، مدیر امنیت می‌تواند به صورت دستی قفل دائمی اعمال کند. قفل حساب فقط از طریق یک فرآیند امن (مانند تأیید از طریق ایمیل یا تماس با پشتیبانی) قابل برداشتن است. این کنترل به طور چشمگیری موفقیت حملات Brute-force را کاهش می‌دهد، زیرا مهاجم نمی‌تواند در مدت زمان معقول تعداد کافی رمز را امتحان کند.
به منظور مدیریت دقیق هویت و مجوزهای کاربران، سیستم دارای مجموعه‌ای از مشخصات امنیتی برای هر کاربر است که شامل شناسه یکتا، نقش‌ها، مجوزها، وضعیت احراز هویت، تاریخ انقضای رمز عبور و تعداد تلاش‌های ناموفق می‌باشد. این مشخصات هنگام ایجاد حساب کاربری مقداردهی شده و در طول زمان تنها توسط مدیر امنیت و از طریق کانال‌های امن قابل تغییر است. هیچ کاربر عادی نمی‌تواند مشخصات امنیتی خود را تغییر دهد.
با توجه به نقش کلیدی رمزهای عبور در امنیت احراز هویت، سیاست رمز عبور با اعمال قوانین سختگیرانه زیر پیاده‌سازی شده است: حداقل طول ۱۲ کاراکتر، شامل حروف بزرگ و کوچک، اعداد و نمادها، ممنوعیت استفاده از رمزهای رایج (مانند "123456"، "password") و ممنوعیت توالی کاراکترهای تکراری یا متوالی (مانند "aaaa" یا "1234"). همچنین، رمزهای عبور در پایگاه داده با استفاده از الگوریتم bcrypt (عامل هزینه ۱۲) و با salt یکتا به ازای هر کاربر ذخیره می‌شوند.
به منظور جلوگیری از دسترسی غیرمجاز، پیش از اعطای هرگونه دسترسی به عملکردها و داده‌های سیستم، از کاربر هویت‌اش با استفاده از ترکیب «نام کاربری + رمز عبور قوی» و در موارد حساس با احراز هویت چندعاملی تأیید می‌شود. مکانیزم احراز هویت در برابر حملات تکرار (Replay attack) با استفاده از یکبارمصرف کردن توکن‌ها و ثبت زمان دقیق هر درخواست محافظت شده است.
برای جلوگیری از شنود یا دستکاری داده‌های خروجی در حین انتقال (مثلاً دانلود فایل توسط کاربر)، تمام کانال‌های خروجی ملزم به استفاده از TLS 1.3 با رمزگذاری قوی شده‌اند. فایل‌های خروجی قبل از انتقال، توسط سرور امضای دیجیتال می‌شوند تا کاربر بتواند اصالت آن‌ها را تأیید کند. همچنین، در صورت امکان، داده‌های بسیار حساس با یک کلید یکبارمصرف رمزگذاری شده و کلید از طریق کانال جداگانه (مانند پیامک) به کاربر می‌رسد. این اقدام امنیت داده‌ها را در مسیر انتقال تضمین می‌کند.