이제
마지막 Exchange Server를
재울 시간입니다.

Microsoft 365를 위한 SMTP 릴레이입니다. 프린터, 스캐너, 앱은 계속 메일을 보내고, 서버는 마침내 잠듭니다.

프리뷰 신청

아직 출시 전입니다. 프리뷰가 곧 제공됩니다.

Microsoft Partner of the Year Award 수상 또는 최종 후보, Security MSSP of the Year 최종 후보

Session 4f9c1a02 · 198.51.100.24

[ connection accepted from 198.51.100.24 ]

220 ESMTP Service ready

EHLO mfp-3f-canon.contoso.local

250 AUTH LOGIN PLAIN NTLM

AUTH LOGIN

235 Authentication successful. Let's send some emails!

MAIL FROM:<scan@contoso.com>

250 2.1.0 Sender OK

RCPT TO:<accounting@contoso.com>

250 2.1.5 Recipient OK

RCPT TO:<anyone@gmail.com>

550 5.7.1 Recipient not authorized

DATA

250 2.6.0 Queued mail for delivery

Sendman은 Microsoft 365를 위한 정책 적용형 SMTP 릴레이로, 일반 SMTP만 사용할 수 있는 모든 프린터, 스캐너, 애플리케이션을 위해 만들어졌습니다. 이들을 Microsoft Entra ID로 인증하고, IP 주소와 발신자 정책으로 범위를 제한하며, 메일을 Exchange Online이나 이미 사용 중인 전송 서비스에 넘깁니다 — 결과적으로 마지막 온프레미스 Exchange Server에는 더 이상 할 일이 남지 않습니다.

문제프린터 때문에만 존재하는 서버

거의 모든 조직에 Exchange Server가 한 대 남아 있습니다. 그 서버에서 메일을 읽는 사람은 아무도 없습니다. 스캐너, 야간 ERP 내보내기, 경보 장치가 메일을 보내야 하기 때문에 여전히 돌아가고 있을 뿐이며, 이들이 할 줄 아는 것이라고는 포트를 열고 인증하는 것뿐입니다.

우회책

네 가지 막다른 길

누구나 이 중 하나쯤은 시도해 봤습니다. 어느 것도 오래가지 않습니다.

01
Exchange Server를 계속 운영한다
스캐너가 PDF를 이메일로 보낼 수 있도록 메일 서버를 패치하고 있는 셈입니다. 이제 Exchange 보안 권고가 나올 때마다 주말이 사라집니다.
막다른 길: 서버는 남는다
02
인증 없는 내부 릴레이를 연다
커넥터에 접근할 수 있는 것이라면 무엇이든 도메인의 누구 명의로든 보낼 수 있습니다. 신원도, 발신자 통제도, 나중에 감사할 것도 없습니다.
막다른 길: 통제는 사라진다
03
메일박스 비밀번호 하나를 200대 장치에 넣는다
모든 장치를 일일이 방문하지 않으면 교체할 수 없고, 그 사본은 복사실 스티커에 붙어 있습니다.
막다른 길: 통제는 사라진다
04
모든 것을 대량 발송 서비스로 돌린다
전달은 됩니다. 하지만 누가 누구 명의로, 누구에게 보내는지 중간에서 확인하는 것이 없고, 공유된 API 키는 사실상 도메인 전체 발신 권한과 같습니다.
막다른 길: 통제는 사라진다
05 · 탈출구
네 가지 모두 같은 거래입니다. 장치를 위해 메일 서버를 계속 살려 두거나, 누가 누구 명의로 보낼 수 있는지에 대한 통제를 포기하거나 둘 중 하나입니다. Sendman은 이 거래를 거부하는 선택지입니다.
탈출구: 서버는 없애고, 통제는 유지

온프레미스 Exchange의 릴레이 기능을 대체

Exchange Online 또는 외부 전송 서비스로 라우팅

Exchange Online이 전부 처리합니다. 내부 사용자에게 가는 메일과 외부로 나가는 메일 모두 마찬가지입니다. 또는 Azure Communication Services나 다른 SMTP 전송 서비스 등 이미 사용 중인 서비스에 전달을 맡길 수도 있습니다. Exchange Online에는 SMTP AUTH 없이 연결되므로 Microsoft의 기본 인증 폐지는 이 경로에 전혀 영향을 주지 않습니다. 메일 흐름은 그대로 유지되고, 중간에 있던 서버만 사라집니다.

레거시 SMTP 로그인, 최신 ID

장치와 애플리케이션은 늘 하던 방식대로 LOGIN, PLAIN 또는 NTLM으로 계속 로그인합니다. Sendman은 그 자격 증명을 Microsoft Entra ID로 검증하며, 앱 등록도, 동의도, 테넌트에서 변경할 것도 없습니다. CONTOSO\svc-scan 같은 하이브리드 로그인도 그대로 작동합니다. Entra ID에 존재해서는 안 되는 계정은 AES-256-GCM으로 암호화되는 Sendman 자격 증명 볼트에 넣습니다. 로그인이 전혀 불가능한 장치는 대신 IP 범위로 제한합니다.

도메인별 분리 라우팅

메일 경로를 공유해서는 안 되는 사업부, 자회사, 도메인은 먼저 정책으로 분리합니다. 사용자별, IP 범위별, 발신자와 수신자별로 나눌 수 있습니다. 그것으로 부족하면 해당 조직 단위에 자체 구성과 자체 백엔드를 갖춘 별도의 Sendman을 두어 아무것도 공유하지 않게 합니다.

기존 설정 그대로 유지

스캐너, 경보 장치, 업무용 애플리케이션은 OAuth를 배울 수 없고, 상당수는 STARTTLS조차 지원하지 않습니다. 이들은 가진 것을 그대로 유지합니다. 호스트 이름, 포트, 사용자 이름, 비밀번호입니다. 그 호스트 이름을 Sendman으로 향하게 하면 이전과 똑같이 포트 25, 465 또는 587로 메일을 보냅니다. 대부분의 경우 DNS 레코드 하나만 바꾸면 됩니다.

한 세션, 처음부터 끝까지

Sendman은 SMTP 대화 옆이 아니라 그 안에 있습니다. 무언가를 결정하는 순간은 다섯 번입니다. 하나를 골라 대화의 어느 부분을 관장하는지 확인해 보세요.

Session 4f9c1a02 · 198.51.100.24

[ connection accepted from 198.51.100.24 ]

[ 198.51.100.16 – 198.51.100.31 is on the allow list ]

220 ESMTP Service ready

EHLO mfp-3f-canon.contoso.local

250-STARTTLS

250 AUTH LOGIN PLAIN NTLM

STARTTLS

220 TLS go ahead

EHLO mfp-3f-canon.contoso.local

250 AUTH LOGIN PLAIN NTLM

AUTH LOGIN

334 VXNlcm5hbWU6

c3ZjLXNjYW5AY29udG9zby5jb20=

235 Authentication successful. Let's send some emails!

MAIL FROM:<scan@contoso.com>

250 2.1.0 Sender OK

RCPT TO:<accounting@contoso.com>

250 2.1.5 Recipient OK

RCPT TO:<anyone@gmail.com>

550 5.7.1 Recipient not authorized, your account is not permitted to send to this address

DATA

354 Start mail input; end with <CRLF>.<CRLF>

250 2.6.0 Queued mail for delivery

QUIT

221 2.0.0 Service closing transmission channel

직접 해보기

세 가지 정책. 누가 문을 두드리는지 바꿔 보세요.

실제 평가 순서가 그대로 실행됩니다. 먼저 허용 목록, 그다음 이 ID와 이 주소에 적용되는 정책, 그다음 발신자, 마지막으로 수신자 하나하나입니다. 네 가지 중 무엇이든 바꿔서 릴레이가 어떻게 응답하는지 확인해 보세요.

누가 연결하는가

어디서 연결하는가

MAIL FROM

RCPT TO

Evaluation

connect220 ESMTP Service ready

auth235 Authentication successful. Let's send some emails!

policypriority 10 applies

mail from250 2.1.0 Sender OK

rcpt to250 2.1.5 Recipient OK

queued250 2.6.0 Queued mail for delivery

이유

우선순위 10 정책은 198.51.100.24 주소에서 오는 svc-scan@contoso.com에 대해 범위가 지정되어 있습니다. scan@contoso.com 주소는 허용된 발신자와, accounting@contoso.com 주소는 허용된 수신자와 일치하므로 Sendman은 백엔드로 자체 세션을 열고 메시지를 변경 없이 넘깁니다.

평가되는 정책

전역 허용 목록: 198.51.100.16 – 198.51.100.31, 192.0.2.128 – 192.0.2.143

우선순위 10Entra ID

svc-scan@contoso.com, 본사에서

senders: scan@contoso\.com
receivers: .*@contoso\.com

우선순위 20Sendman 볼트

mfp-3f, 허용 목록의 어디서든

senders: .*@contoso\.com
receivers: .*@contoso\.com

우선순위 30익명 허용

본사의 모든 장치, 로그인 없음

senders: noreply@contoso\.com
receivers: .*@contoso\.com

정책은 범위로 선택된 뒤, 적용되는 것 중 가장 낮은 우선순위 번호로 좁혀집니다. 우선순위가 같은 정책은 병합되므로 한 장치가 여러 규칙에서 동시에 권한을 부여받을 수 있습니다.

기능

Exchange의 마지막 역할, 거기에 통제까지

레거시 장치가 계속 작동하려면 세 가지가 필요합니다. 통신할 포트, 이해할 수 있는 인증 방식, 그리고 권한입니다. Sendman은 이 세 가지를 모두 제공하고, 세 번째를 여러분의 통제 아래 둡니다.

Entra ID 인증
사용자 이름과 비밀번호는 그대로 계속 작동하며 Microsoft Entra ID로 검증됩니다. 앱 등록도, 동의도, 테넌트에서 변경할 것도, 동기화할 디렉터리도 없습니다.
하이브리드 로그인 그대로 작동
몇 년 전에 CONTOSO\svc-scan으로 구성한 장치도 계속 작동합니다. Sendman이 도메인 로그인을 올바른 Entra 사용자로 확인하므로 장치에서 다시 입력할 것도 없고 프린터 앞에 갈 사람도 필요 없습니다.
자체 자격 증명 볼트
디렉터리 ID를 가져서는 안 되는 장치에는 대신 Sendman 자격 증명을 발급합니다. AES-256-GCM으로 저장되고, 상수 시간으로 비교되며, 다시는 표시되지 않습니다. 백엔드 비밀번호도 마찬가지입니다.
LOGIN, PLAIN, NTLM
오래된 하드웨어가 실제로 구현하는 세 가지 방식입니다. Microsoft 365 앞단에서 NTLM을 여전히 지원하는 것은 거의 없습니다. 각 방식은 개별적으로 끌 수 있습니다.
전역 IP 허용 목록
범위는 연결이 수락되는 즉시, SMTP 그리팅보다 먼저, 포트 465에서는 TLS 핸드셰이크보다도 먼저 평가됩니다. 그 밖의 모든 것은 인증은커녕 대화 자체에 도달하지 못합니다.
우선순위가 있는 정책
규칙의 범위를 사용자 이름, IP 범위 또는 둘 다로 지정합니다. 적용되는 것 중 가장 낮은 우선순위 번호가 이기며, 같은 우선순위의 규칙은 병합되므로 한 장치가 여러 규칙에서 권한을 물려받을 수 있습니다.
발신자 및 수신자 통제
양쪽 모두 정규식으로, MAIL FROM과 모든 RCPT TO에서 적용됩니다. 아무도 CEO 명의로 보낼 수 없고, 실수로 오픈 릴레이가 되는 일도 없습니다.
의도된 익명 릴레이
일부 장치는 인증 자체가 불가능합니다. 이런 장치에는 좁은 통로가 주어집니다. 의도적으로 켜야 하고, IP 범위로 한정되며, 발신자와 수신자 규칙은 여전히 적용됩니다.
모든 포트에서 TLS
465에서는 암시적 TLS, 25와 587에서는 STARTTLS를 사용합니다. 인증서는 발급받거나 직접 가져올 수 있으며, 재시작 없이 갱신됩니다. 백엔드로 이어지는 구간은 백엔드가 지원하는 경우 암호화됩니다.
어떤 백엔드로든 발송
SMTP AUTH 없이 Exchange Online으로, 즉 Microsoft의 기본 인증 폐지에 영향받지 않고 보내거나, Azure Communication Services 및 다른 전송 서비스로 보냅니다. 전환은 재배포가 아니라 설정 하나입니다.
다음 연결부터 즉시 적용
구성은 세션이 열릴 때마다 새로 읽힙니다. 정책을 수정하면 다음에 연결하는 장치에 이미 적용됩니다. 재시작도, 변경 시간대도, 기다려야 할 캐시도 없습니다.
경고를 걸 수 있는 메트릭
모든 세션은 인증, 전달, 세션 시간 같은 흔적을 남기며, 포털에서 검색하고 경고를 설정할 수 있습니다. 발송을 멈춘 장치는 지원 티켓이 아니라 쿼리 하나로 찾아냅니다.
이름 그대로의 역할
뷰어는 모든 규칙을 보되 아무것도 바꾸지 못하고, 관리자는 구성을 변경합니다. 서비스가 모든 요청에서 이를 적용하며, 모든 항목은 누가 만들었는지 기록합니다. 정책은 마지막으로 누가 변경했는지도 기록합니다.
검색 가능한 이벤트 로그
모든 인증 실패와 정책 위반을 사용자, 주소, 발신자, 수신자로 필터링할 수 있으며, 거부한 규칙이 항목에 명시됩니다. “왜 반송됐지”라는 질문은 검색 한 번이면 끝납니다.
로드맵 예정
스니프 모드
캡처 창을 열고 장치가 실제로 무엇을 제시하는지 확인합니다. 원본 주소, 제시하는 사용자 이름, 주장하는 발신자입니다. 아무도 비밀번호를 모르고 어떤 공급업체도 더 이상 지원하지 않는 프린터를 위한 기능입니다.

한눈에 보기

사양

관리자가 첫 테스트 메일을 보내기 전에 묻는 이름과 숫자들입니다.

연결

포트: 25와 587은 STARTTLS, 465는 암시적 TLS
인증서: 발급받거나 직접 가져오기, 재시작 없이 갱신
허용 목록: IPv4 주소 범위, 범위당 최대 16,384개 주소

인증

메커니즘: LOGIN, PLAIN, NTLM
ID 원본: Microsoft Entra ID(하이브리드 DOMAIN\user 로그인 포함), Sendman 자격 증명 볼트
볼트 암호화: AES-256-GCM

정책

범위: 사용자 이름, IP 범위 또는 둘 다
우선순위: 가장 낮은 번호가 우선, 동순위는 병합
발신자 및 수신자 규칙: 정규식, MAIL FROM과 모든 RCPT TO에서 적용
익명 릴레이: 정책별, IP 범위에 한정

전달

백엔드: Exchange Online(SMTP AUTH 없음), Azure Communication Services, 기타 SMTP 전송 서비스
메시지 크기: 메시지당 최대 25 MB(백엔드에 따라 더 작을 수 있음)
처리: 변경 없이 통과, 큐 없음, 사본 보관 없음

운영

구성: Platform Portal, 다음 연결부터 적용
역할: 뷰어, 관리자
텔레메트리: 포털에서 검색 가능
포함 사항: 모든 업데이트, 인시던트 지원
보유 인증: 당사의 개발 및 운영팀은 ISO 27001 인증을 받았습니다

얻는 것

마지막 Exchange Server를 없애야 하는 이유

Sendman이 릴레이를 넘겨받으면 서버는 사라져도 됩니다. 그때 얻게 되는 것은 다음과 같습니다.

더 작은 공격 표면
온프레미스 Exchange는 가장 많이 공격받는 워크로드 중 하나입니다. 마지막 서버가 사라지면 주말에 패치할 Exchange CVE도, 경계를 노리는 제로데이도 더는 없습니다.
인터넷에 남는 것이 없음
OWA, ECP, Autodiscover, Exchange 웹 서비스가 네트워크 경계에서 사라집니다. 초기 침투 진입점 하나가 줄고, 원격 코드 실행 표적 하나가 줄어듭니다.
Exchange 패치 작업 종료
테스트하고 설치하고 모니터링할 누적 업데이트와 보안 업데이트도, 그에 따른 유지 관리 시간대도, 다음 중요 수정이 나올 때 뒤처질 Exchange Server도 없습니다.
다음 마이그레이션 없음
Exchange 2016과 2019는 2025년 10월에 지원이 종료되었고, Subscription Edition이 다음 업그레이드로 예정되어 있습니다. 서버가 없으면 계획하고, 예산을 잡고, 버텨내야 할 다음 마이그레이션도 없습니다.
권한 있는 시스템 하나 감소
Exchange는 AD에 깊이 얽혀 있고 높은 권한을 가집니다. 이를 제거하면 자격 증명 탈취의 주요 표적이 사라지고, SOA 이전 후에는 AD에 남아 있던 흔적 대부분도 함께 사라집니다.
운영할 것이 줄어듦
Exchange를 위해 운영할 모니터링, 백업, 인증서, 스토리지, VM이 없고, 작성하고 테스트하고 최신으로 유지할 별도의 재해 복구 계획도 없습니다. 모든 체크리스트에서 워크로드 하나가 줄어듭니다.
더 깔끔한 아키텍처
메시징은 Exchange Online, 그것으로 끝입니다. 하이브리드 예외 사례도 없고, 메일 흐름, Autodiscover, 수신자, 인증에 문제가 생겼을 때 점검할 구성 요소도 줄어듭니다.
유지해야 할 노하우 감소
온프레미스 Exchange 전문 지식은 점점 귀해지고 비싸집니다. 돌볼 서버가 없으면 그 지식을 계속 보유하거나, 그것을 아는 유일한 사람이 휴가 중일 때 외부에서 사 올 필요가 없습니다.
더 명확한 역할, 더 낮은 비용
인프라, 운영, 백업, 모니터링, 관리 부담이 줄어듭니다. Microsoft가 플랫폼을 운영하고, 여러분은 Exchange Online을 관리하며, 둘 사이의 경계가 마침내 분명해집니다.

Sendman을 백엔드로 연결
Sendman을 백엔드로 연결
Exchange Online, Azure Communication Services 또는 이미 발송에 사용하는 호스트를 선택하고 필요한 정보를 입력합니다. 포털의 양식 하나면 되고, 변경 시에도 재배포가 필요 없습니다.
장치를 들여보내고, 무엇을 할 수 있는지 정하기
장치를 들여보내고, 무엇을 할 수 있는지 정하기
장치가 연결하는 IP 범위를 추가하고, 디렉터리 ID를 가져서는 안 되는 장치에는 볼트 자격 증명을 발급한 뒤, 누가 어떤 명의로 누구에게 보낼 수 있는지 정책으로 작성합니다.
DNS를 변경하고 서버 폐기
DNS를 변경하고 서버 폐기
장치가 메일을 보내는 호스트 이름을 Exchange Server 대신 Sendman으로 향하게 합니다. 이상적으로는 그것이 전부입니다. 장치는 한 대도 건드리지 않고, Exchange Server에는 더 이상 할 일이 없습니다.

알아 두면 좋은 것

가장 먼저 나오는 질문들

관리자가 첫 테스트 메일을 보내기 전에 묻는 것들입니다.

01Sendman이 우리 이메일을 저장하나요?

아니요. SMTP 세션을 프록시하여 도착하는 그대로 전달합니다. 메일박스도, 큐도, 스풀도, 아카이브도 없으며, 메시지 자체는 헤더를 포함해 변경 없이 통과합니다. Sendman이 보관하는 것은 구성뿐입니다.

02Entra 테넌트에 무언가를 등록해야 하나요?

아니요. Sendman은 앱 등록도, 동의도, 테넌트에서 변경할 것도 없이 장치 자격 증명을 Microsoft Entra ID로 검증합니다. CONTOSO\svc-scan 같은 하이브리드 로그인도 그대로 작동합니다.

03해당 계정의 다단계 인증은 어떻게 되나요?

어느 쪽도 방해가 되지 않습니다. 볼트 자격 증명은 디렉터리를 전혀 거치지 않으므로 프롬프트가 뜰 이유가 없습니다. Entra ID 계정도 마찬가지로 작동합니다. 다단계 인증과 조건부 액세스는 엄격한 정책에서도 방해가 되지 않으며, 장치는 프롬프트를 보지 않습니다. 계정이 어떤 명의로 누구에게 보낼 수 있는지는 Exchange Online의 메일박스 권한이 아니라 Sendman 정책이 정합니다. 볼트 자격 증명이든 Entra ID 계정이든 발신자와 수신자 규칙이 결정합니다.

04장치가 TLS를 전혀 지원하지 않으면 어떻게 하나요?

일반 포트로 계속 연결할 수 있으며, ID, IP, 정책은 완전히 같은 방식으로 적용됩니다. 그 장치의 암호화되지 않은 첫 구간을 허용할지는 여러분의 결정입니다. 허용 목록이 이를 자체 이그레스 주소로 제한하고, Sendman부터는 백엔드가 지원하는 경우 세션이 암호화됩니다.

05SPF, DKIM, DMARC는 어떻게 되나요?

이들은 발송 도메인에 속하며, 실제로 전달하는 백엔드인 Exchange Online이나 Azure Communication Services가 처리합니다. Sendman은 엔벨로프나 헤더를 다시 쓰지 않으므로 해당 백엔드에 설정해 둔 것은 지금과 똑같이 계속 작동합니다.

06Sendman이 구성에 접근할 수 없으면 어떻게 되나요?

연결은 일시적인 “service not available” 응답으로 거부되며, 이는 정상적인 발신자에게 메시지를 보류하고 재시도하라고 알립니다. 따라서 스토리지 장애가 있어도 메일은 유실되지 않고 지연될 뿐입니다.

07Exchange Online을 백엔드로 계속 사용할 수 있나요?

예. 많은 조직이 Exchange Online을 전달 경로로 유지하면서 장치에 필요한 인증과 정책 계층으로 Sendman을 사용합니다. 백엔드는 나중에 장치를 하나도 건드리지 않고 변경할 수 있습니다.

08구성은 어디에 저장되고 누가 볼 수 있나요?

테넌트별로 격리된 스토리지에 저장됩니다. 자격 증명은 기록되기 전에 암호화됩니다. 포털 접근은 플랫폼 테넌트에서 이루어지며, 뷰어는 모든 규칙을 보되 아무것도 바꾸지 못하고, 관리자는 구성을 변경하며, 모든 허용 목록 항목, 정책, 자격 증명은 누가 만들었는지 기록합니다.

09장치가 실제로 무엇을 보내는지 어떻게 알 수 있나요?

모든 인증 실패와 정책 위반은 검색 가능한 이벤트 로그에 기록되며, 거부한 규칙이 항목에 명시되고, 장치가 받는 응답은 어느 관문에서 거부되었는지 알려 줍니다. 장치가 제시하는 원본 주소, 사용자 이름, 주장하는 발신자를 정확히 보여 주는 캡처 창인 스니프 모드는 로드맵에 있습니다.

직접 만나요

Sendman이 올가을 행사에 나갑니다. 들러서 프린터 이야기를 들려주시고, 릴레이가 작동하는 모습을 확인해 보세요.

Sep

2026년 9월 14~17일 | 서밋 | 바덴

Workplace Ninja Summit

Microsoft 엔드포인트 관리 및 보안을 주제로 바덴에서 열리는 커뮤니티 콘퍼런스

Oct

2026년 10월 27~29일 | 전시회 | 뉘른베르크

it-sa

유럽을 대표하는 IT 보안 전시회에서 올해도 만나요

glueckkanja의 다른 제품

클라우드 기반 RADIUS 서비스 RADIUSaaS

마지막 Exchange Server가 온프레미스에 남은 유일한 서버인 경우는 드뭅니다. 흔히 RADIUS 서버가 아직 Wi-Fi를 지키고 있습니다. RADIUSaaS는 이를 클라우드 기반 RADIUS 서비스로 대체하여 Wi-Fi, LAN, VPN의 장치를 인증서로 인증하고, 장치가 인증서를 처리할 수 없는 경우에는 사용자 이름과 비밀번호로 인증합니다. SCEPman이나 Microsoft Cloud PKI, Intune 및 Jamf 관리 장치, 그리고 Aruba, Cisco, Fortinet, Juniper, Meraki, UniFi 등의 네트워크 장비와 함께 작동합니다. RADIUSaaS는 Microsoft Azure에서 고가용성 서비스로 실행되므로 직접 운영할 RADIUS 서버가 남지 않습니다.

RADIUSaaS 자세히 알아보기

클라우드 네이티브 인증 기관 SCEPman

이미 온프레미스 Exchange를 폐기하는 중이라면 클라우드 네이티브 인증 기관 SCEPman도 유용할 것입니다. Intune 및 Jamf 관리 장치, 서버, 네트워크 인프라를 위한 X.509 인증서의 발급, 갱신, 검증, 폐기까지 전체 수명 주기를 자동화하여 레거시 ADCS 배포를 대체합니다. SCEPman은 전적으로 여러분의 Azure 테넌트에서 실행되거나, RADIUS as a Service와 함께 관리형 서비스로 제공됩니다.